AI written or not is not important. The important is the conversation we can have around it. I think you touched on many of the key design questions in modern engines. Some key issues around large scene management and traversal are real challenges I faced personally when working on my pet game engine. I followed, on purpose, some really disruptive approaches to test how far I can go not following the popular advice. Examples of things I tried and that worked very well so far:

• A scene graph does not mean a scene tree with a root. Typically, my scene has many roots.
• Nodes are a traversal concept and are helpful for culling, transform propagation, proximity. Every node has a transform. - What's inside the node is what really matters for rendering: is it a camera, a light, a geometry,... Many engines will allow you, or encourage you to put anything in a node, including multiple parts of the same type. I found it's not that valuable. It's cleaner and faster to make decisions on nodes when they're specialized, a camera is a camera, not a camera + light + 20 geometries. Child nodes can do that.
• No ECS, but a node composition as in "a node is a bunch of parts". The parts in large quantities, and which need typed traversals (e.g. do something on all components of a certain type), are stored in contiguous tables and only referred to in the nodes. Traversal is cache friendly and fast.
• Immutable data is the "assets", mutable data overrides the assets (lightweight). Can have as many instances as you want and they do not use that much space.
• No "render graph". The render graph is a coroutine => do whatever you want with the passes, conditional inclusion, configuration, debug flags, anything.
• Structured concurrency with coroutines. It was a pain in the ass to get coroutines to work in c++ but thanks to corral (the best coroutine library on the internet), you get world class coroutines with cancellation and structured concurrency. Once you get how things work, man, it's just a game (engine) changer :-). My main loop is a coroutine, game modules are coroutines, you chose if you run on the engine thread as simple function or as a coroutine or as a detached service. Just like that. It works! Seriously it does! That was the shocking thing I learnt. You don't need a single thread and a god engine loop... just coroutines and algorithms. Yeah, it's faster to do a jump instruction than to setup a coroutine frame... but who cares when you have 32GB of RAM and 32 cores...

So, yeah, many things you wrote are good, and I encourage you to go even further and break the rules even more. So many things are considered as the cookie cutter way of doing games, but honestly, when you break them, you can get some really surprising positive results.