Besides, for simple games, using those engines are a huge overhead and an unnecessary cost.
I understand what you're saying, but I don't like how you make it sound a simple, already-made-for-you decision, when reality is much more nuanced. Each case is a case, and no one should turn down their critical sense when making these decisions, there are no rules.
I don't think the pricing of $0-$75/month is a huge cost. They made some big changes to their fee structure this year.
Or put differently: Simple games probably have so sleek game logic code that the engine overhead can safely be ignored.
I don't say custom engines are pointless, but for the hundreds of games that are released on the App Store daily, a ready to use engine is "enough".
My main point is still that this should be a decision that you make when starting a project, not one that has presumably been made for you. Team members expertise, project cost, for how long you'll be using the tech you're developing, etc. should all be taken into account.
A practical example: Imagine trying to optimize loading times when the whole resource system is a massive generic thing that has been made for you. Now imagine having to support a new platform. You could be in a bind simply because you're using third-party tech (especially if closed-source).
The big companies with their in-house engines will be able to pay someone to do the job.
None of which develop for Mac.
For simple games, you're probably not going to be reaching down to the Metal layer anyway. You're probably gonna stay up at the CoreGraphics layer, use SpriteKit/SceneKit, or something like Cocos or something similar.