I believe there's value in showing that making a complete game without an engine can be simple and straightforward. And not only it is simple and straightforward, there's *little* work necessary to replicate workflow and the parts which make Unity (and similar engines) appealing.
Showcasing that the tech parts necessary in a non-triple-A game is a very small subset of what is commonly referred to as a "game engine".
I don't think that there are many materials that cover that at all.
Especially interplay of tech code and non-trivial-amounts of non-trivial gamecode.
If anything this minimalistic approach would encourage people to experiment with tech as it shows that it's easy and approachable to get running. And that any tech of any complexity can be easily tailored as necessary when necessary.
There are certain aspects of HMH which make it very appealing for this.
HMH has a non-dogmatic approach, without any preconceived notions of how software development should be done.
That is very refreshing and rare.
But it certainly doesn't display the razor sharp prioritization and pragmatism necessary to ship games outside of game-production-machine where you might have a separate guy doing sweaty ass-cheek physics for the latest iteration of EA NBA game.
They might even have a whole R&D dep toying with tech for making dudes sweat realistically.
Arguably, as it currently stands HMH is training fit for being a specialized cog moreso than anything else really.
Not that there is anything wrong with doing "tech for techs sake". Or toying around with tech. Or being a cog.
It's also clearly not exactly what it says on the tin.
Which is why every once in a while you are bound to get threads like this one.
how to be the most efficacious at completing specific game project X.
Has nothing to do with it. Given very finite resources outside of game-production-machine it's a matter of getting stuff done at all.