I must say looking at the other blog posts and their clickbaity titles, it sounds very much like a click-harvesting operation. Especially considering that the blog just started a few months ago, there's a good chance it's generated to profit from AI angst.

I think nearly every definition of MVC I've read has been different. At this point it just means you split something into three classes as far as I can tell.

After having worked on my own (2D) game engine [1] for about 5 years now and having worked on related stuff for paid work I'd like to explain one thing that many people might not find so obvious.

Engines are the easy part.

The real meat & potatoes is all the tooling and content and asset pipelines around the engine. If you think about it, you need to implement:

  -  importing data from various sources and formats, textures, audio, model files such as gltf, fbx, animations etc etc.
  - editor app with all the expected standard editing features, cut, copy, paste, undo, redo, save, delete etc. 
  - all the visualizations and operations that let the game developer use the editor to actually create and manipulate data, entities, animations, scenes, audio graphs, scripting support etc. etc.
  - all the data packaging and baking such as baking static geometries, compiling shaders, resampling and packing textures, audio, creating game content asset packs etc
  - etc etc.

And this is just a small sample of all the features and things that need to be done in order to be able to leverage the engine part.

When all this is done you learn that the actual game engine (i.e. the runtime part that implements the game's main loop and the subsystems that go brrr) is actually a rather small part of the whole system.

This is why game studios typically have rather small teams (relatively speaking) working on the engine and hordes of "tools" programmers that can handle all the adjacent work that is super critical for the success of the whole thing.

[1] https://github.com/ensisoft/detonator