It sounds like you're talking about making an equivalent of Super Mario from the 80s, but modern games are in fact much more complex.
And no, just because people in the 80s enjoyed Super Mario doesn't mean it's the pinnacle of game design, and that there's no need to create anything more complex.
> It took less than a month of work for me to get a polished cross-platform system working on five platforms.
You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet. That is especially true regarding consoles with their custom hardware and mobile devices with their abundance of cheap, often not well engineered hardware and sketchy drivers.
"Modern games" span a wide range of things. I develop solely 2D games, because I prefer 2D games over 3D games. I think that even today 2D games are more enjoyable than 3D games. That doesn't mean Super Mario Bros. That can mean Europa Universalis IV, it can mean Stardew Valley, it can mean Magic the Gathering Online, it can mean Hollow Knight, it can mean Slay the Spire, it can mean a huge variety of interesting and engaging games, none of which require 3D graphics. 2D games can be as complex as you'd like them to be, far more complex in game logic than a 3D shooter even. The more complex you'd like them to be, the easier it gets to implement them if you understand the primitives you're implementing them with. Imagine trying to optimize your data structures when you don't even know what an int32 is? There are real game developers in the world who don't know even that much. It is a great thing that off-the-shelf game engines provide a level of accessibility to allow anyone to develop games, but they do not represent the pinnacle of what can be achieved in software engineering. They are the exact opposite of it, in fact.
> You simply don't know where the bugs and performance pitfalls are because you haven't encountered them, yet.
What is your point? I profile my games and have detailed logging systems. If I or my users run into performance issues, I address them as I come across them. Understanding my codebase at a low level makes it significantly easier to dig into problems and investigate underlying root causes than anyone on Unity will ever be able to. If you use Unity, you are putting your complete faith that Unity has perfectly optimized X low-level problem away at the engine level. If they haven't, and you run into that issue in your game, you are completely fucked. I love being solely responsible for the defects in my games. That means I can fix them myself. The worst thing in the world in software development is when somebody else's fuck-up becomes your problem, and you can't fix it, so you have to implement some hacky workaround, if you can even figure out why the closed-source engine code you didn't write and can't read is behaving incorrectly to work around it in the first place. Sometimes that still happens anyways -- our hardware-OS stacks are built with tens or hundreds of millions of line of dogshit code, and you can't get around it if you want to create software for platforms people use, but you can at least remove as many dependencies on bad code you have no understanding of as possible.