Pretty much every engine out there is built on strong opinions about “how game code should be structured” so while you almost always can bring your own opinions like this, you are likely to make life difficult for yourself…

It very much depends on what kind of game you’re making but I actually don’t think Godot is actually all that unsuitable for the sort of separation of concerns you’re going for, though you’re unlikely to find many tutorials geared towards that style of coding.

I say this as someone with similar instincts about how to structure my code, who spend 2-3 years working against the grain in UE4 to maintain a clear model/view separation in a 2D simultaneous-turn-based strategy game & am currently going down a similar route with Godot.

You can use plain Node & Resource derived classes for a lot of your model-side stuff & only use “things that automatically draw themselves” nodes as a layer on top of that if needs be… but yeah, it very much depends on what kind of game you’re making. For most traditional real-time games (as opposed to turn-based ones etc), especially anything 3D or where you want to use in-built physics stuff, I’d lean towards trying to work with the engine as much as possible, rather than being too fanatical about following a particular design pattern that isn’t fully encouraged by the engine… at least for your first game or two!