For one, making an real game, requires creating a tool chain. Programming on the raw level means your tool chain easily integrates directly in no matter what kind of niche game you make. As long as you're forward thinking with your code (ala unit testing/modular architecture), adding something like a "in game renderer" to any of your tools (so your artists see exactly what it'll look like in real game), will take a single work day or less.
But if you're just making a game that looks/feels like 99% of what's out there (omg another platformer on steam!) then you can often save time by going with a third-party framework. However, there are the classic negatives of not being able to know if a problem is your fault, or a bug in the engine, and if there is a bug can you get the devs to fix it in time (or are you stuck working around it through insane means).
But again, in real 3-D games, the pendulum swings the other way and you gain WAY more by using Unreal/Unity than trying to roll your own. You can get 80% of the performance and quality of the best programmers with their dedicated, custom 3-D engines, and instead of investing 3 man-years of your life to make ONE ENGINE you could you know... be working on a game instead. GTA V (custom engine) runs on TONS more computers than PUBG (Unreal). But GTA V had >$100 million dollar budget, and PUBG started with a team of like 5 people.
But when it's 2-D games, there's still tons of room for either using a small framework that allows you fine control, or, making your own engine. Factorio would be nearly impossible (or slow as hell) without an engine that can take advantage of specific game similarities/assumptions appropriate only for Factorio.
The main game I've been working toward is going to be an ultra-lean networked game. The entire game is on the server with only blind, dumb clients. The clients merely send their keyboard/mouse input (which is verified server-side). You can't hack data that you're never given. (Like off-screen players positions.) Likewise, there's tons of optimizations related to my specific game universe / game mechanics. I've been looking into basically multi-threading... a single-threaded game. The game is mostly in space with space stations. Groups of rooms connected by long walkways. One natural optimization is treating every group-of-rooms as a single entity with its own memory space in RAM and CPU core. Any data that needs to "sync" across these groups of rooms (a bullet passing through, or a chat message) is synced, but otherwise, they're separate "simulations." The goal is at least 100 (possibly 200) players per server with very very low lag and a high simulation tick rate while running on normal internet connections. When you're doing fluid simulations on gigantic grid "worlds", being able to split the workloads into multi-threads is a big deal.
Tons of other things too. User mods are a strong part of the game and community.
I'm also using a D backend with a Lua front end for scripting with TONS of scripts (almost every object in the game is scripted with common cases off-loaded to the D binary.)
Probably plenty of other stuff but the point is, anything a computer can do (even off-loading physics calculations into CUDA cores to utilize your GPU to simulate my simple 2-D graphics game) I can do. I've even considered off-loading logic to those 200 connected peers with majority rules voting to reduce the burden on the server. The more players there are (normally slowing down the server), the more total distributed computing is available in the "network".
Many of those optimizations, I probably won't even need. I'm basically re-implementing a decade old, super-complex game, that runs on a piece-of-crap single-threaded interpreted-language "game system" that was never designed to implemented the physics (finite element/finite difference method) that was built into the game. So merely re-writing it in a real langauge like C++/D will almost guarantee a real 100x speed-up. And since I'm directly controlling the packet structure, I can optimize them to reduce spurious wastes of bandwidth generated by a "generic" engine written by a couple of dudes who may have no idea what they're doing (and never planned for their engine to be used for a game like this).
Basically, I'm re-writing my own Space Station 13 if anyone knows what that is.
And BYOND (the engine) is written in a Java VM (remember how slow Minecraft was?), that is then an interpreter for their custom language, that is all single-threaded and server-side. The "best" servers top out at around 100 players because after that (and also some in-game events) destroy the performance down to 1 FPS or less. The engine has almost NO support for multiple graphics layers, no easy support for animations or blending/coloring. The sound is super basic and has no support for "3-D" (well 2-D in this case) sound based on propagation rules. (I'm a big sound nut so my version will definitely improve the sound big time.) The game engine, which is Java, running a custom intrepretted language, is then used (read: abused) into running 2-D finite element physics calculations. The entire game was originally a 4chaner's physics engine built in the BYOND engine for fun during his grad school. Then people bolted on an entire game onto that. But fundamentally, BYOND is the WRONG TOOL for doing physics and the entire game (as someone with extensive playing and modding experience in the engine) is a "bad fit" for the engine.
They also have horrible encapsulation issues where BYOND supports Linux, but, certain "games" written in BYOND... like SS13.. don't actually work. Ugggghhhh...