For games and demos, static is the usual. In terms of CPU use and program space it's usually the most efficient. If you let your screen address be at the mercy of the OS then you'd likely be doing same with PMG addresses.
In cases where extended Ram banks are used there is a lot more flexibility to be had at little effort though because the addresses you deal with are still the same, the bank numbers rather than dealing in absolutes can be stored in a table of allowable banks. The reason some demos have select screen to choose which banks to use is to allow the user to preserve Ramdisk contents when it's being used for that.
The problem with doing things "by the book" - you then may as well cater for any possible Dos footprint.
Which means $700 - $3000 or greater in low memory goes untouched. Memory under the OS might be used by Dos, as well as extended Ram banks @ $4000.
Since any Ram outside 48K of the original 800 wasn't in the original specs there's no official provision for allocating it or flagging it as being in use. It's a case of use at your own risk of stomping or being stomped.
But that's the nature of 6502. Very simple memory management, no Ram virtualisation or protection facility, single shared stack space, and assumed single-tasking with coldstart between old/new tasks.
Good programming practice these days is to either coldstart when the user presses Reset or to allow your program to terminate and return to a usable Dos if it was present beforehand.
If you're doing some hardcore game or demo that uses a lot of resources though, that isn't necessarily practical. But it is nice that some programs and games are being done that way.
To do it that way though you either have to save/restore a bunch of memory or not touch it at all. In the least, any semi-complex game or demo will need a decent slice of Page 0 Ram, but save/restore of that is trivial.