Most decent engines and frameworks give the functionality that you need, and never get in your way.
Do they? That rather depends on exactly what it is that you are doing, graphically speaking.
For many kinds of games, there are standard answers for graphical questions. The average 2D game for example can be handled just fine with the 2D prowess of, for example, XNA/MonoGame. It's just sprites, which can come in batches for terrain, can be rotated, and so forth.
But what if your game used to be the average 2D game, then you read about some cool technique, such as using a height map to build an imposter that has the appearance of depth relative to the screen. And you want to do that.
Now you're employing normal mapping and even possibly parallax mapping. All in the same context of "rendering sprites", but requiring more than a lot of pure 2D engines can handle. Specifically, it requires multitextured "sprite blitting", which is not something that many 2D engines can do.
What do you do if your engine can't adapt with you? So that means you have to do multiple passes, one for the color and one for the lighting via normal map. But that doesn't work, because you need the normal map's height field to employ parallax mapping to the color lookup. So... now what? You need the alpha to do transparency, so you can't steal the alpha. And the engine just doesn't support multitextures.
So you must pick one of the following:
- Abandon the idea. This means that your game is functionally limited by your engine.
- Hack the engine to have multitexture. Assuming you have access to the source code, you are now taking it on yourself to poke at someone else's code. This also means you need to maintain it and not break it with your stumbling around.
- Do the best you can, within the limitations of the engine. So you can get parallax on the normal maps, but not on the colors. It may not be exactly what you wanted, but it's better than nothing.
Just as an example, take Geometry Wars. Most 2D engines would suck at these kinds of visuals, since most of them are built around drawing sprites, not lines. That's a game that needs a very specialized kind of renderer.
At the end of the day, you need to take responsibility for the elements of your game that are important to the needs of your game. If your game's visual look is primarily developed by the art style of the images and models you use, rather than specific effects, then using a pre-packaged solution is fine. But if your game's visual style is defined significantly by custom rendering code, odds are good that a standard engine could become a serious limitation if you decide to do things that are outside of the box.
Furthermore, there's a very practical issue: not all game engines are equally portable.
With the recent rise of mobile platforms, the marketplace for games is spread across numerous OS's and user-interface devices. Not all engines work on all devices. And if your engine doesn't work on a platform, you're certainly not going to take the time to make it work on one. After all, that's why you used an engine in the first place, right?
If it's important to you that your game function on a particular platform, then you again need to take responsibility for it. And the "easiest" way to ensure success with this is to do it yourself. To build an engine that can work across multiple platforms, perhaps employing simpler platform-specific frameworks where needed to handle some low-level details. That way, if it breaks, it's your code; you're the best person to be able to fix it.