What seems to me the easiest-to-think-of advantage is that similar files live in the same directory tree. Configuration files live in /etc, log files and/or run-time trace files live in /var/log, executables live in /usr/bin, run-time information like PID files lives in /var/run. You want to know what's in the NTP configuration file? Change directory to /etc and do ls ntp*. You want to have some program watch executable files so that some traditional file system virus doesn't infect them? Everything in /usr/bin and /usr/local/bin needs watching.
The second advantage I can think of is that the Unix style of organization promotes a separation of data and executable. Executables live in a directory that's well away from where templates live (/usr/share, probably), and well away from where data lives. That separation might be a reason why Unix/Linux/*BSD have more resistance to file system viruses than Windows does, or the old Pre-OSX Mac had.
Comparing filesystem structures
We want to compare filesystem structures looking for non-aesthetic differences.
We compare hierarchical filesystems with a tree structure of directories,
with flat filesystems that have only one place that contains all files, similar to a single directory with no subdirectories.
The two main types of differences are in CPU time, and in memory use.
Another type that could be relevant here is the complexity of implementation.
Performance of file access
The performance of listing directories depends on the file count of the directory.
Even in hierarchical filesystems, it can be a problem to list files in a directory to delete them, if they are many.
That all is not relevant for only thousands of files, but for hundredthousands in each of 100 directories, you better not put them all in a flat filesystem, or all in one directory.
The problem is that a directory listing is going through the whole list - because no tree is used inside the directory.
To find a file, about half of the file names must be read, on average.
For 1000000 files in a flat filesystem, that means we need to read 500000 names.
In a tree structure, we could use two levels of the tree by splitting the files into 1000 directories, with 1000 files each. To find one, we need to read 500 names on average on each level, 1000 in total.
We could als use three levels with 100 entries. We'd need to read 150 names on average.
With this example calculation, it's plausible that a tree structure can easily be much faster than the flat filesystem, like 2000 times as fast.
Multiple uses
Part of the tree in a hierarchical filesystem can be used for some separate purpose, while not using the rest for that purpose:
For example, you can mount another filesystem - flat or not - into a subdirectory of a hierarchical filesystem.
Mounting into the flat filesystem makes as little sense as mounting into the root of a hierarchical filesystem.
Permissions
A tree-structured filesystem has subsections - the subdirectories - which you could assign permissions.
In a flat filesystem you can not make someone see only part of the file names.
To change permissions in a flat filesystem, for part of the files, is not possible all at once - it needs changes on each individual files permissions, and may take seconds or minutes while the permissions are unclear and changing.
Small and simple
Flat file systems can have advantages in ressource limited environments - in embedded systems.
A flat file system implementation can be very simple. And as long as the count of files to handle is small, it can even be faster than a hierachical filesystem!
A hardware device may need to store a list of files, each labeled with a number, and never more than 1000 at once. For this task, using a flat filesystem makes sense if it allows to use a smaller processor, resulting in longer battery life.
The simplicity of a flat filesystem can also be helpful to make sure the filesystem does not have bugs in the implementation.
Best Answer
It's true that file's data is "flat" on the actual disk drive. Most (all?) modern disk drives have "LBA" (Logical Block Addressing), which means that even to the kernel, a disk is a great big line of blocks. The blocks containing a file's data might be interrupted, because inodes, etc, get spaced out throughout the line of disk blocks. So "flat" is a bit deceptive as a description.
It's also true that the "hierarchy" part is just a fiction: folders (better referred to as "directories") and their membership get their arrangement from the kernel "making it so" by reading file names and matching inode numbers from a directory's data.
But a hierarchical arrangement of data is pretty useful. As long ago as 1991, people were arguing about that, and getting refuted soundly. See Brent Welch's The File System Belongs In The Kernel for a better argument than I can compose.
I also feel compelled to note that Microsoft has embarked on a file-system-as-database at least twice in the last 20 years, and abandonded it both times, but maybe I'm interpreting what Google says incorrectly.