Well, the problem as I see it is that people use the term too loosely, inasmuch as they refuse to specify what kind of "GAME ENGINE" they're referring to.
It's not that "Game Engines" aren't full-fledged things, which handle all aspects of the game...
...or that they can be.
The problem is that a Physics Engine is an engine which is self-contained, and will accept inputs of things to do work on, and will output the equivalent in work, after the engine transforms the input.
So is a Lighting Engine.
So is a Graphics Engine.
So is a Sound Engine.
All of these things meet the qualifications of being an "engine", as a lexicologist might consider it, in the abstract sense, and all of these engines are game engines, in that they are all engines predominantly written to be used in games.
The extra layer of frustration comes in when you consider that you can have an overarching game-management engine, which wraps ALL of the other engines, as plug-ins, or as bolt-ons.
This is something which doesn't really happen often, in the real world, except when thinking more of fully-autonomous corporate subsidiaries...
Dell bought Alienware -- Alienware is still allowed to do its own thing, in a modular and self-contained way, but the self-contained entity known as Dell has wholly-encapsulated it (with a few "API" Alienware-branded touchpoints left exposed).
So now, most of the functionality of Alienware is still held by Alienware, still self-contained, still a revenue-engine...
...but it's owned and operated in a loosely-coupled fashion by Dell, who, themselves, are their own revenue-engine.
OpenGL isn't really an engine, because there's nothing particularly self-contained about it.
There are no well-defined inputs and outputs.
Consider it like Calculus -- something goes in, you know what's coming out.
A graphics engine might be one where the resource-management engine hands the graphics engine the textures, and the physics engine hands the graphics engine the transformed polygons, and then the graphics engine will make all of the magic happen, and can be loosely coupled through bolt-on/plug-in interfaces to work with OpenGL or OpenGL ES2.0 or DirectX or Canvas/JS or Flash/AS3 or a software renderer, based on switches, but without other graphics work happening externally.
Is it an engine? Sure. You've got well-defined inputs and outputs, you've got known quantities/properties for input (fuel) and you have expected results.
Wrapped inside of a game-engine, is a specific engine still an engine? Yes.
Do fans/journalists/etc get the distinction between Rage being an overarching game-engine, Havok being a physics engine and Euphoria being an AI+physics "natural and procedural animation" engine?
Is it still an engine?
Also: "game engines" aren't a requirement at all.
Pong is totally doable as a bunch of procedurally-called lines in Notepad.exe
But as complexity of game-code, as well as complexity of visual and state-managing (RPGs) expectations rose, engines made life better, whether they were physics engines, graphics engines, lighting engines, sound engines, combat engines, stat engines or just flat-out engine-configuring/running engines...