In general, however, I kind of get the impression that game development is much less rigorous even than normal software engineering, and that things are less well-architected, much more ad hoc/hackier, etc. Is there any truth to this?
In game development, especially with indies, in the early phases of development many developers take an approach of valuing "getting it going" over everything else. While this might sound short-sighted, it's actually a very canny decision, and often is the only way to gain enough of a foothold to ensure the long-term success of the project when you're working on a very complex piece of software like a game - see Jonathan Blow's youtube video on "The art of getting things going". Additionally there's the relationship of this approach with the game design process, where you need a very fast iteration time on prototyping game mechanics in the early stages, to start finding your way towards something interesting to flesh out into a full product.
With that being said, in commercial game development (and experienced indie developers), the performance standards are so much higher than most other fields of programming that it is actually absurd. The focus on performance of much of enterprise software, web apps, and even most native tools, is nowhere even in the same league as that of high-quality games.
I would also say that at the highest level of game development there is a very high quality level of code organization and architecture. Games are one of the most complex types of programs, involving physical simulation of a large amount of objects, skeletal animation skinning, very complex rendering and shading, realtime deterministic state synchronization over a network, audio streaming, and on, and on, and on, all happening on a realtime basis.
There's simply no room to be "ad hoc" or "hacky" in AAA gamedev because the systems involved are so complex that their architecture has to be extremely robust to even be able to finish the game at all. In my opinion, other fields of programming have a lot to learn from the lessons of game development, but unfortunately gamedev is a bit of an insular field and there's not much cross-pollination between gamedev and other industries.
Or you could just look at it like this:
AAA Gamedev: Formula 1 car
Google / AWS : State of the art metropolitan high-speed rail system
Enterprise Software: Diesel bus service
Native apps and tools: Sedans, hatchbacks, vans, sports cars
Web apps: Bicycles
Electron apps: Bicycle with a lawnmower engine welded to the frame that tops out around 20mph and gets 3 miles to the gallon
If startups are a risky venture, video games are insane, and video game startups essentially doomed to failure.
Your window for sales is the first few months after release. After that they generally slow to a trickle. Microtransactions get brought in to rectify that situation, but then further increase the risk that players will reject your game en masse.
Spending time to make a beautiful architecture doesn't make sense. Companies that sell game engines have an incentive to do things right, but spend too long and you'll lag behind the competition in shiny features and your customers will jump ship to things that help them sell games.
Key to game development is to iterate fast and fail fast. Building up a prototype and getting it to a state where it's "fun" is crucial, and then the sunk costs fallacy kicks in and the prototype gets cleaned up and shipped.
Players are unconcerned with bugs despite often complaining about them. The success of early access games like Minecraft, Day Z, and PlayerUnknown's Battlegrounds despite often gamebreaking bugs proves this.
The disconnect between quality and success has become so pronounced that an entire subgenre of "simulators" has popped up where the core gameplay mechanic is the game being buggy and/or frustrating to play. Goat Simulator, Surgeon Simulator, Getting Over It with Bennett Foddy, and Hand Simulator come to mind here, but there are plenty more.
At the game studios I've worked at, programmers created unique designs that worked really well for the games they were made for, usually created and maintained by a single person. These things are rarely evangelized due to lack of time, resources, or need (games still come in boxes, and the codebase doesn't need to live forever.) An outside engineer might see it and think it's poorly designed because they haven't seen the pattern on HN.
I think that we'll see more robust engineering discussion from game programmers as games as a service becomes more the norm.
This is all anecdotal, and I'd like to hear what others think.
And of course Mike Acton's classic talk:
CppCon 2014: Mike Acton "Data-Oriented Design and C++"
All these resources are CPU oriented. As next gen GPUs begin to dominate for data queries. It will be interesting to see how the game changes as well.
The Rise of the GPU: How GPUs Will Change the Way You Look at Big Data