Q:

Why is Linux's filesystem designed as a single directory tree?

Can anyone explain why Linux is designed as a single directory tree?
Whereas in Windows we can have multiple drives like C:\, and D:\, there is a single root in Unix. Any specific reason there?

A:

Since the Unix file system predates Windows by many years, one may re-phrase the question to "why does Windows use a separate designator for each device?".  
A hierarchical filesystem has the advantage that any file or directory can be found as a child of the root directory.  If you need to move data to a new device or a network device, the location in the file system can stay the same and the application will not see the difference.
Suppose you have a system where the OS is static and there is an application that has high I/O requirements.  You can mount /usr read-only and put /opt (if the app lives there) onto SSD drives.  The filesystem hierarchy doesn't change.  Under Windows this is much more difficult, particularly with applications that insist on living under C:\Program Files\

A:

This is partly for historical reasons, and partly because it makes more sense this way.
Multics
Multics was the first operating system to introduce the hierarchical file system as we know it today, with directories that can contain directories. Citing “A General-Purpose File System For Secondary Storage” by R.C. Daley and P.G. Neumann:

Section 2 of the paper presents the hierarchical structure of files, which permits flexible use of the system. This structure contains sufficient capabilities to assure versatility. (…)
For ease of understanding, the file structure may be thought of as a tree of files, some of which are directories. That is, with one exception, each file (e.g., each directory) finds itself directly pointed to by exactly one branch in exactly one directory. The exception is the root directory, or root, at the root of the tree. Although it is not explicitly pointed to from any directory, the root is implicitly pointed to by a fictitious branch which is known to the file system. (…)
At any one time, a user is considered to be operating in some one directory, called his working directory. He may access a file effectively pointed to by an entry in his working directory simply by specifying the entry name. More than one user may have the same working directory at one time.

As in many other aspects, Multics sought flexibility. Users can work in a subtree of the filesystem and ignore the rest, and still benefit from directories to organize their files. Directories were also used for access control — the READ attribute allowed users to list the files in a directory, and the EXECUTE attribute allowed users to access files in that directory (this, like many other features, lived on in unix).
Multics also followed the principle of having a single storage pool. The paper does not dwell on this aspect. A single storage pool was a good match with the hardware of the time: there were no removable storage devices, at least none that users would care about. Multics did have a separate backup storage pool, but this was transparent to users.
Unix
Unix took a lot of inspiration from Multics, but aimed at simplicity whereas Multics aimed at flexibility.
A single hierarchical filesystem suited Unix well. Like with Multics, storage pools were usually not relevant to users. However, there were removable devices, and Unix did expose them to users, via the mount and umount commands (reserved to the “super-user”, i.e. the administrator). In “The UNIX Time-Sharing System”, Dennis Ritchie and Ken Thompson explain:

Although the root of the file system is always stored on the same device, it is not necessary that the entire file system hierarchy reside on this device. There is a mount system request with two arguments: the name of an existing ordinary file, and the name of a special file whose associated storage volume (e.g., a disk pack) should have the structure of an independent file system containing its own directory hierarchy. The effect of mount is to cause references to the heretofore ordinary file to refer instead to the root directory of the file system on the removable volume. In effect, mount replaces a leaf of the hierarchy tree (the ordinary file) by a whole new subtree (the hierarchy stored on the removable volume). After the mount, there is virtually no distinction between files on the removable volume and those in the permanent file system. In our installation, for example, the root directory resides on a small partition of one of our disk drives, while the other drive, which contains the user's files, is mounted by the system initialization sequence. A mountable file system is generated by writing on its corresponding special file. A utility program is available to create an empty file system, or one may simply copy an existing file system.

The hierarchical filesystem also has the advantage of concentrating the complexity of managing multiple storage devices into the kernel. This meant that the kernel was more complex, but all applications were simpler as a result. Since the kernel has to care about hardware devices but most applications don't, this is a more natural design.
Windows
Windows traces its ancestry back to two lineages: VMS, an operating system originally designed for the VAX minicomputer, and CP/M, an operating system designed for early Intel microcomputers.
VMS had a distributed hierarchical filesystem, Files-11. In Files-11, the full path to a file contains a node name, an account designation on that node, a device name, a directory tree path, a file name, a file type and a version number. VMS had a powerful logical name feature allowing shortcuts to be defined to specific directories, so users would rarely have to care about a directory's “real” location.
CP/M was designed for computers with 64kB of RAM and a floppy drive, so it went for simplicity. There were no directories, but a file reference could include a drive indication (A: or B:).
When MS-DOS 2.0 introduced directories, it did so with a syntax that was compatible with MS-DOS 1 which itself followed CP/M. So paths were rooted at a drive with a single-letter name. (Also, the slash character / was used in VMS and CP/M to start command line options, so a different character had to be used as a directory separator. This is why DOS and later Windows use backslash, though some internal components also support slash).
Windows retained compatibility with DOS and the VMS approach, so it kept the notion of drive letters even when they became less relevant. Today, under the hood, Windows uses UNC paths (originally developed by Microsoft and IBM for OS/2, of related ancestry). Although this is reserved for power users (probably due to the weight of history), Windows does allow mounting through reparse points.

A:

There are no security concerns behind having a single directory tree.
The guys who designed Unix had a bunch of experience with operating systems that required users to know what physical device contained a given resource. Since part of the purpose of an operating system is to create an abstract machine on top of real hardware, they thought it much simpler to dispense with addressing resources by their physical location and decided to put everything into a single tree of names.
This is only one part of the genius behind the design of Unix.

