So my first professional programming job was at a place where people described themselves as "C# developers" instead of software engineers. The team was run by a guy who had built his entire career out of teaching people a very dogmatic, .NET-specific flavor of MVP that he'd learned from a Learning Tree course without understanding any of its theoretical underpinnings. He augmented his One True Design by looking up ASP .NET hacks and tricks on StackOverflow, implementing them, then copying the source code for each project that he worked on to a USB key so that he could reference his handiwork at later jobs. Because this was a step above people writing unintelligible 3000-line classes he was hailed as a minor hero by management. His teachings created a professional quasi-religion where he was the Pope and his USB key full of copy-pasted jQuery selectors and Linq statements was the Bible.
In this hallowed religion one of the most fundamental rules was that every domain object had to have both an integer identifier ("ID") and a UUID ("GUID", because Windows). When I asked why we didn't simply use one or the other I was told that we had to have an ID because we "need a primary key" and a GUID because "we can't put an ID in the URL because then you can go to another record by changing it!" It didn't matter that we performed permissions checks on these routes because _security_. As I learned more about data modeling and relational databases I periodically questioned this (in retrospect we should have just used UUIDs as the PK because we had no good performance or design reasons to have both) but never got a good answer. This religion didn't tolerate heretical nonsense - GUIDs are for URLs because of hackers.
No idea if that's what's going on here but it reminded me of it.