Yes it is a burden, it’s the price I pay for peace of mind. 
Also I’ve created a little workaround for DispVM startup time but beware (!!!) if used in a wrong way it will negate the advantages of edit/view in a DispVM.
The idea is to move the time penalty to the end of the session (shutdown, restart) instead of the beginning (e.g. have a DispVM pre-loaded). However if you then go an edit multiple files in the same session or forget to shutdown/restart you’ve shot yourself in the foot and the entire advantage of using DispVM’s is out the window. SO PROCEED WITH CAUTION and be sure you understand what you are doing!
I don’t, but one could to keep data compartmentalized. It’s a trade off between compartmentalization and ease of backup.
Since I follow the ‘never edit/view in storage qube’ rule strictly, I allow myself the exception of having it all be in the vault qube.
Nothing special at all here. Just make sure it doesn’t have a NetVM set and optionally base it on a minimal template to prevent yourself from accidentally viewing/editing anything in it. You’d probably want to install some packages in that template like a file manager, but that’s another topic. Make sure to consult the documentation should you choose to go down this route.
If you’d open an infected file (e.g. an office document with a macro exploit) it could potentially spread to other files stored in the same qube. I am assuming that files might be malicious no matter where they came from. As long as I only edit/view them in an offline disposable nothing really bad could happen – right? The malicious code executes in the dispVM, has only access to the file it came from and “dies” once the disposable closes.