Unity is a good example. It promises ease, but is packed with bugs which you can't fix: it will kill projects or force you to hack workarounds. All the time savings of using an engine are lost to incredibly frustrating, usually inscrutable bugs (because you can't access the code to diagnose them).
For example: race conditions in animation events (killed a game jam project), contact filters not being passed to 2d collisions in the API (added days of debugging to a simple prototype, has since been fixed), list/arrays causing the editor to bug out and require a restart after editing one (in the LTS version in 2026 - unforgivable).
Sure, don't roll your own SDL (but also if you can, do - you'll be a better game developer for it). Do for example roll your own animator - you don't need their features, clarify what you actually need and design for that. Do you want to trigger scripts with frames? Should those scripts be executed before the next frame, or with it? Do you need a bones/rigging system? How should those bones warp the mesh exactly for your visual style? A game isn't just a collection of scripts moving objects around, it's a pipeline of design intentions from bottom to top. Someone else's engine will be mediocre for your project at best, and inheriting their bugs and workflows is far more painful than designing and fixing your own.
Even with frameworks like monogame, you inherit their asset pipeline and rendering API decisions. Better to create exactly what you need, and understand it.
Even when you reach the deployment phase, you'll be hit with errors and incompatibilities you couldn't foresee. E.g. the Signalr .net library is incompatible with WebGL builds, so have fun maintaining an additional js signalr bridge for your WebGL build separate to your editor build.