Godot, Unreal, CryEngine, and even Unity... all solve edge-cases most don't even know they will encounter. Trying something custom usually means teams simply run out of resources before a game ships, and is unlikely stable on most platforms/ports. =3
But even more complex custom/inhouse engines are usually not written from scratch, those are often mostly glued together from specialized middleware libraries which solve the tricky problems (e.g. physics engines like Jolt, vegetation rendering like SpeedTree, audio engines and authoring tools like FMOD or WWise, LOD solutions like Simplygon, etc etc...)
Most game engines are broken by default. Modern customers just aren't very discerning ("It's for the pigs. Pigs eat slop."). You can feel holes and rough edges in the vast majority of new releases, including AAA titles.
Unreal is the worst for this and Unreal-based games almost always have two things in common: a very particular, soft, sticky and unresponsive look & feel (often alleviated but never fully corrected by turning off some combination of motion blur, AA and VSync), as well as a UI that mishandles mouse pointers.
Unity devs seem to rely on a (more diverse but still quite) small pool of subsystems and renderers; possibly some mix of baseline and Asset Store components. This gives each Unity game a specific subset of flaws from a wider common pool. That is, you can tell that game A uses the same movement subsystem as games B and C (but not D), that game B uses the same UI subsystem as games C and D (but not A), and that game D uses the same rendering subsystem as games A and B (but not C).
Forcing devs to use a mid-grade GPU also tends to reduce chasing performance issues later. For example, high frame-generation artifacts users often perceive as "floats" or "wobbly". =3
Besides not all games need performance, I have been working on a clone of the original elite game using SDL. It gets 6000 fps easily.
[0]: https://ookigame.com
I could never jell with C++ until I had Cursor hold my hand (especially around the build system), and now I feel like I am developing games with a razor sharp knife that I could never before access. The patterns associated working directly with memory suddenly clicked and now it’s the only I want to build games.
I still don't use it (AI) for the game programming as it sucks the joy out of it for me. Especially when AI usage is currently being pushed hard at work.
But I haven't reached to the more tedious parts, like doing skeleton animation on GPU and testing cross platform (SDL should be naturally cross platform, but I never tested it...), etc. The most tedious part, imo, is to build your own 3D scene editor.
At very least I can say SDL has reached a passable state for 3D. It doesn't support some modern features like bindless though.
And one doesn't need to stich with C++ if they don't want to. SDL is pure C and if your favorite language can call foreign function it's not that hard to make it work with SDL.
I think that if I were making something in 3D or I were more serious I'd use an engine, but I've found that I get more satisfaction from building tools than from learning how to use tools that other people have built.