A directory is a file (and IIRC e.g. Plan 9 decided they should be readable just like normal files and there shouldn't be any special readdir syscalls). You can see its attributes to figure out the rest.
If not for strong Linux limitations (because of alleged hardlink knot-tying problem) and belief that it just cannot be both, transparent archive access through a filesystem would be a thing. As well as metadata access (`play ./file.mp3` vs `edit ./file.mp3/id3v2`). People of the past seemed to have paid great attention to interoperability and effort to make common interfaces; folks of the modern age ('00s and later) love unique and completely incompatible solutions to the same problem.
This was possible in the beginning. But then came the moral police and deprived us of this freedom, because they deemed it to be "confusing".
See, for example, The Unix Programming Environment, by Kernighan and Pike, page 51 [0]:
Despite their fundamental properties inside the kernel, directories sit in the file system as ordinary files. They can be read as ordinary files. (...) The time has come to look at the bytes in a directory:
Valid complaint, but maybe not such a great reason.
It gets worse when you deal with sysfs or procfs and similar. It all becomes obscure magic, like what values can be written into what file, why some files aren't readable, or the contents of files being just a bunch of numbers which you have no way of interpreting.
Another problem is that there's way too many of different file types and they aren't organized into any kind of hierarchy or any other meaningful order. This makes tools like rsync extremely complicated, with loads of footguns and still not solving the problem well. It feels especially bitter because in exceeding majority of cases you don't want tools like rsync to deal with named FIFO or device files or sockets etc. but you get accidentally but painfully bitten by them every now and then.
'ls -l' will tell you the basic information of a given listing, including whether it's a normal file, directory, symlink, block device, named pipe, etc.
stat(1) will provide additional information on a file.
file(1) will not only distinguish between filesystem=level distinctions, but will make a remarkably good guess as to what the file contents of a normal file are, based on magic(5).
Yes and no. While it simplifies things to an extent, it's also confusing, especially with extension-less files.
Example: Tell me, is this a file or directory?
It could be a file that curls todays posts, or it could be a folder (directory) that contains them.