I'm looking at the ability to render as many entities as possible to the screen before it drops the frame rate below 60 FPS.
Honestly, you're going to run into a ton of actual rendering-related bottlenecks before a decently architected game object/entity/"whatever buzzword you want to use" system gets in your way. Don't start theoretically optimizing things. Solve the problems you have at hand to get to the desired frame time for your specific game.
Spread that 16ms out to every system??? Are you trying to run every system at 60FPS? That's wasteful and pointless....
You've obviously never worked on any type of shooter before. Try telling that to people designing any type of competitive game which supports split-second inputs. 16ms in a game update tick can definitely make a difference.
Not to mention there's the option to run your rendering on a seperate thread asynchronously, which most games don't even do anymore.
What are you talking about? There's a ton of games doing async rendering? The era of single-threaded update and render is over!
Still looking for more improvements that will make this even more efficient. But my question is actually really simple, how fast are your engines running and what specific design patterns are you using to improve how many simultaneous entities can exist and be drawn without slowing your engine down. I'm trying to find a goal to shoot for and new ideas to improve my own engine.
This is still a very useless comparison to make. You're acting like every engine is comparable in some shape or form when it comes to performance. They're not. Focus on what your requirements and goals are. Do some profiling, find your bottlenecks, fix them. Rinse and repeat.