Simple 2D games don't need all the runtime components that a triple-A game needs, yet a game engine for 2D games is just as much a game engine as an engine used for triple-A games.
This is a good time to point out we're really arguing over the definition of a word here, and can probably agree on a lot of facts and observations, even if we don't agree on what the definition of "game engine" should be.
And on the opposite end, if the Unity editor is considered part of the engine, why not Visual Studio, Photoshop and Maya/3dsMax/Blender too?
In the end, the engine is just that fuzzy layer between the high level gameplay code and the operating system (going with my own preference that "engine" should only be used for the runtime parts).
Yes.
Engines are essentially loops. There are many examples of engines in software and hardware. Processors, virtual machines, emulators: they are execution engines looping over instructions that they decode and execute. Game engines are the same: they loop over user input, logic and audivisual output. Every game will have this loop deep inside, no matter how it was programmed. It is essential to their operation.
Modern game engines are generalizations of that loop. People took the common functionality from successful games and separated it from the game-specific code.
For things like audio and asset loading, you can get really far building on top of a library like SDL2 or GLFW as a cross-platform system interface, and using some single-header libraries for things like loading models or playing audio samples. There are also great physics libraries out there like Chipmunk or Bullet which neatly encapsulate most of the "hard stuff" in building a game engine.
For something like a 2D platformer for example, it's perfectly reasonable and easier than ever for a solo developer to take on building a small custom engine.
Load("Asset.png");
That wasn't so hard