The cold hard truth, however, is that CP/M is kind of awful. Back then you didn't have directories and subdirectories, what you had were floppies and disk drives. These were your file management components. Hard drives were rare, and CP/M was just not very friendly to large disk spaces.
User areas had a marginal affect at the time, since they were really considered more apt to their name "User area", as in "separate users", vs a mechanic to actually organize files.
Out of the box CP/M had really poor support for user areas. The simple fun fact that the way you shared a command across user areas was to...copy the file in to each user area. Which is easier said than done.
The file copy program, PIP, could copy files FROM one user area to another (i.e. pull a file from one user area in to your current one), but not TO another user area.
So, in order to copy files in to a user area, you had to have a copy of PIP in that user area. But you can't use PIP to move PIP in the first place. You have to jump through hoops loading PIP into memory with the debugger to span user areas.
Later, new shells and utilities supported the idea of A3:FILE.TXT to represent user area 3 on drive A, started becoming common, but not every program supported it, and the stock OS did not support it either. Recall, in CP/M, the programs did most of the heavy lifting for this stuff.
It's unjust, honestly, to criticize CP/M looking backward. It managed to empower great things back in the day, which is what microcomputing was all about. Its influence is felt to this day. But that doesn't necessarily mean it was a great place to be.
CP/M wasn't that terrible. Some of my first paid development work circa 1985 was writing dBase II apps, with WordStar as an editor, on CP/M on a rather nice NEC PC. It did enough to allow small/medium sized businesses to start "computerising" their workflows for not staggering sums of money.
User areas had a marginal affect at the time, since they were really considered more apt to their name "User area", as in "separate users", vs a mechanic to actually organize files.
Out of the box CP/M had really poor support for user areas. The simple fun fact that the way you shared a command across user areas was to...copy the file in to each user area. Which is easier said than done.
The file copy program, PIP, could copy files FROM one user area to another (i.e. pull a file from one user area in to your current one), but not TO another user area.
So, in order to copy files in to a user area, you had to have a copy of PIP in that user area. But you can't use PIP to move PIP in the first place. You have to jump through hoops loading PIP into memory with the debugger to span user areas.
Later, new shells and utilities supported the idea of A3:FILE.TXT to represent user area 3 on drive A, started becoming common, but not every program supported it, and the stock OS did not support it either. Recall, in CP/M, the programs did most of the heavy lifting for this stuff.
It's unjust, honestly, to criticize CP/M looking backward. It managed to empower great things back in the day, which is what microcomputing was all about. Its influence is felt to this day. But that doesn't necessarily mean it was a great place to be.