I agree with the above, I believe!
As the poster above says, I don’t think that there is one “right” way of doing this; different approaches may work for different people, and different projects.
As to what I myself do (and noting that I’m speaking of Python development, not C++):
I generally seem to have a “framework” class that controls everything–that handles events, that manages which scene is currently active, and so on.
I then have a “world” class (which I imagine would be similar to your “scene” class); depending on the specifics of the game, there might be sub-classes to this that handle various specific sets of functionality. The “world” class is often responsible for managing the various objects of the game–enemies, NPCs, the player, weaponsfire, etc.
And finally, I generally have a “GameObject” class, which is the super-class to most, perhaps all, in-game objects: the player, NPCs, enemies, and so on.
As to NodePaths and the like, I tend to include them into my classes. For example, a “world” class might store the root-NodePath for the level geometry. Similarly, a “GameObject” class might store a “handle” NodePath by which the object is located, rotated, scaled, etc., as well as a “model” or “actor” NodePath/Actor, and perhaps collision NodePaths. Sounds would likewise be stored in their relevant objects–footstep-sounds in a “GameObject” class, for example.
If you want a basic example of this, albeit in Python, my “beginner’s tutorial” follows the above pattern, I believe; perhaps it’s worth taking a look at the reference code for the tutorial and seeing how things are laid out there.
(The reference code is linked in the “Start here” page, I believe.)