Actually, it's more like the Windows (CP/M, rather) way of doing things is inflexible.
In DOS and Windows (including the Windows NT line which has spawned e.g. Windows NT 3.x, Windows 2000, Windows XP and Windows 8), until fairly recently there was a one-to-one mapping between disk partitions and file systems. (This was changed by the introduction of volume mount points in Windows 2000, although that remains a rarely used feature perhaps outside of specialized situations.)
Unix-like systems make a clear distinction between the storage device which holds a file system, the file system itself, and the mount point at which that file system is accessible. This is part of the underlying design, and each piece serves an important role.
In Windows, normally the file system on a partition is accessed through that partition's assigned drive letter (for example,
E:). In *nix, a file system is normally accessed through a directory path (for example,
/export/home possibly relative to the current directory).
The latter is more flexible because in a path, there are no encoded assumptions about the underlying storage. Running out of space on one partition? Just move a large file system that currently exists on that partition to another, update the mount table (in Linux /etc/fstab, might be different on other *nixes) to point the relevant directory to a new physical device, and call it a day. Or split a file system into two by moving a large directory to a file system on a new storage device, and again just update the mount table. Switching to a SAN-based storage architecture rather than per-host storage? Same thing. As far as the users are concerned, this can be done without apparent disruption to anything else aside possibly from the short period of time during which the actual moving of data occurs. Particularly before volume mount points, the same could not be done easily in a Microsoft-centered environment.
When you create a directory
/isos you are creating a directory within the root file system, and the storage of what goes into that directory thus must be supported by the root file system. If you later realize that this storage is inadequate, you can take steps to mitigate or rectify that situation without needing to logically move files around, by creating a separate file system and instead mount that on
/isos and moving the files into the root directory of that file system, making them visible under
/isos when that file system is mounted there.
Keep in mind that Unix was designed as a multi-user system, whereas Windows (and many of the underlying design choices of Windows) traces its lineage back to essentially strictly single-user systems. While this sort of flexibility is likely not needed on a single-user system, it does help greatly in a multi-user setting. (No need for the administrator to pin a notice at the entrance to the terminal room saying "okay everyone, what was previously on D:, except for D:\STUFF, is now on Q:, except for what was in D:\GAMES which is now under R:\WASTE and D:\MATH is now under E:\ALGEBRA, oh and I hope I didn't forget anything"; just shuffle the files around, but keep the logical directories the same.)