If one doesn't understand how a game works, a framework is not going to help. This person will probably shoot himself in the foot.
Here is a good video about benchmarking unity https://www.youtube.com/watch?v=tInaI3pU19Y
Here is a good video about benchmarking unity https://www.youtube.com/watch?v=tInaI3pU19Y
It is no surprise that you can find a benchmark where a general-purpose engine is slow. If you do nothing you go fast, but if you are supporting general-purpose use cases you add a lot of feature overhead, so you become slow. Why do pros use it, then? Because - if the engine is sufficiently extensible - they can use the built-in stuff as a placeholder and replace that subsystem with a custom one later. Project ships, everyone's happy.
With microbenchmarks based around scaling simple elements like "thousands of bullets" like the one in the video this point on general-purpose elements is especially important. As soon as you want to add any additional behaviors to those bullets your performance is going to plummet. And from a game design perspective, scale becomes boring very quickly. A player cannot really appreciate seeing more than a few hundred things on-screen at any moment.
So the way scenes are actually benchmarked in industry is by building out more of the behavior, adding placeholder assets at the estimated level of detail, seeing what frametimes result, and developing a scene budget around that. It all feeds back into the content creation pipeline again, because an optimized scene will have more care given to each of its assets.