Unfortunately, your problems with Google Drive are symptomatic of a deeper set of problems. Changing some settings or switching to other tools or just using Drive differently might create a different set of symptoms, but it isn't going to resolve the core issues.
(Buckle up, this might take a while. The TL'DR version is: You should to have and implement a records retention and disposition plan, as well as a records access plan.)
So, what I take to be your "core" problems:
1) If users are freaking out, it is because the system they are using behaves in an unexpected way. Before you can solve the problems, you need to reset the users' expectations in a way that will allow you to implement solutions. Otherwise, your changes just make the system yet more capricious and unpredictable.
2) If you are relying on a loose set of "a few simple IT rules," you're probably DOA. Competent people make mistakes, and often times their mistakes are more. . . interesting. Competent people can also disagree about the best solution to a problem well after "best" has metamorphosed into "most intuitive." Where you can be flexible, be flexible; where flexibility leads to systemic problems, become rigid. There is no way to figure this out a priori.
The first step is to make sure users have a good idea where a certain kind of record will be. The second step is to make sure users know when a certain kind of record has outlived its usefulness and will therefore die. This is called a records retention and disposition policy (or "guidelines" for the bureaucratically squeamish—your corporate culture and legal needs will determine how "squishy" the records plan can be). A clear plan prevents (reasonable) freakouts, and gives you some wiggle room to start solving your problems.
Personally, I would start with as simple a records schema as you think will pass muster and then when users complain that a node of that schema has become unwieldy you can create subdivisions. If you have time to do a quick review of the research on menu tree design, this will be a huge help to your schema design and revisions.
(ASIDE: Any schema you devise will be somewhat arbitrary. What's intuitive to the goose is not necessarily intuitive to the gander. This is why Drive and similar tools allow users to "symlink" read-only folders into their own folder structure. Using CTRL+click to select multiple locations in Drive's "Move To" panel is incredibly helpful in this regard.)
Now that everyone knows what you're aiming for, you can select and implement tools that reinforce the plan. In your case, it sounds like "LegacyDrive" needs to be a read-only band-aid that holds old data while you migrate all of it into a current data structure. (That is, unless your retention plan calls for 'LegacyLegacyDrive's ad infinitum.) LegacyDrive, and perhaps other drives, will be read-only to avoid simple "Oh my. . ." scenarios, leaving you more time to deal with complex "Oh $#!T. . ." scenarios.
You can use Google Groups to better manage complex access rights (the link refers to Gmail, but the solution proposed there works for Google Drive as well). Google Drive folders generally inherit sharing rights from their parent folder, but you can change the rights for any child folder in any way you like. With a bit of practice and testing, you can create very sophisticated and granular role-based access schemas in Drive (via Groups).
If your corporate culture is such that users are accustomed to deep collaboration (and hallelujah for that), you might include an "open sandbox" folder inside every "closed" folder. The "owner" for the "official" folder can move files into the official folder or make changes there based on discussion in the sandbox. This approach is modeled on how open source software often has a "master branch" with a "maintainer" controlling access to the official build while still providing other areas and opportunities for completely open collaboration. YMMV; make local access and schema decisions as needed.
One other thing to keep in mind: There will be some things that Drive cannot do on its own without a lot of programming work. Sometimes it is easier to act on the files that have been synced to a computer, and to let Drive sync those changes back to the cloud storage. You may, however, need to restart the Google Drive application to get all those changes into the cloud. Drive's "on start" methods for identifying file changes is more thorough than its live methods.
If I've missed anything, well, that's why this answer is a community wiki. Please alter as needed!
Best Answer
If you don't know for sure that you've backed up an application to your G Suite account (i.e. logged in to that Google account when in the app you were trying to back up), it's likely you haven't backed any apps up to that account. For one, if you've only got one WhatsApp number, you can't back up to two Google accounts at the same time, so there isn't a reason to expect that your G Suite account has backed up your WhatsApp account. When there aren't any backups, Google Drive automatically hides that tab.