One nice thing about this setup is you can "stack" processes in the shell.
Say you're working on file_x, but file_x depends on header_file_y and file_z. file_x makes sense on its own, so you don't want to split a new pane; you just want to leave your workspace as it is and come back to it later.
Hit ctrl-z, and fire up vim with the new stuff you want. When you're done, quit the current vim session and come back to your old context with `fg`.
The key observation is this stacks inductively, so you cant tumble down the dependency rabbit hole and always come back to the context you were at originally. This feature alone has made it impossible to ever leave console vi.
It really came in handy in my Operating Systems class where I could fly around the codebase an order or magnitude faster than everyone else.
If you really need to go back to a particular context %[num] lets you go back to the nth suspended process, but this will corrupt your stack of processes, so `fg` won't be in a clean order.
Losing access all your editing state when you move to a new file is silly, regardless of editor.
But I also use ctrl+z frequently, even more when I'm editing over ssh. Usually because I want to do something outside of the editor window not directly related to editing. Or it might be related to editing, it depends, I just want a shell. I may even have forgotten which file contains what I want to edit, so I might back out to a shell and use a find|xargs grep or ack command. Basically any time gedit users open the terminal for something in the middle of editing, I just ctrl+z (or open a new shell tab, but as mentioned ctrl+z is joy on ssh where a new tab means a new connection).
So I use ctrl+z. Also :!bash is stupid, but :r!cmd should be on the page. (It pastes the output of cmd into the file.)
And yeah, you can do every shell action in vim with things like :make and so on and :! when a nice wrapper isn't pre-made, but at that point it starts to feels a little too emacs-y for me in a lot of places and again, frequently I ctrl+z for things orthogonal to what I was working on. Sometimes I do use those wrappers, of course, but it's unnatural in many cases and I think it's of questionable utility compared to mastering the command line normally or compared to other vim features. Linux is my IDE, vim is my editor. I like to have them work together instead of one dominating the other.
That's not a feature of vi(m), that's a part of some shells (bash, zsh). You can suspend any programming running in a shell with ^Z. In addition to getting it back to run in the foreground with 'fg', you could also put it in the background with 'bg' (which is equivalent to starting a program with '&' at the end), or detach it from the shell process with 'disown' to make it a distinct process instead of a child of the shell process (which means it will keep running when you close the shell, which is often useful).
If there is only one a '%' will bring to foreground the last job, otherwise you can do 'fg x' where 'x' is the job number.