While both are designed to contain files not belonging to the operating system, /opt and /usr/local are not intended to contain the same set of files.
/usr/local is a place to install files built by the administrator, typically by using the make command (e.g., ./configure; make; make install). The idea is to avoid clashes with files that are part of the operating system, which would either be overwritten or overwrite the local ones otherwise (e.g., /usr/bin/foo is part of the OS while /usr/local/bin/foo is a local alternative).
All files under /usr are shareable between OS instances, although this is rarely done with Linux. This is a part where the FHS is slightly self-contradictory, as /usr is defined to be read-only, but /usr/local/bin needs to be read-write for local installation of software to succeed. The SVR4 file system standard, which was the FHS' main source of inspiration, is recommending to avoid /usr/local and use /opt/local instead to overcome this issue.
/usr/local is a legacy from the original BSD. At that time, the source code of /usr/bin OS commands were in /usr/src/bin and /usr/src/usr.bin, while the source of locally developed commands was in /usr/local/src, and their binaries in /usr/local/bin. There was no notion of packaging (outside tarballs).
On the other hand, /opt is a directory for installing unbundled packages (i.e. packages not part of the Operating System distribution, but provided by an independent source), each one in its own subdirectory. They are already built whole packages provided by an independent third party software distributor. Unlike /usr/local stuff, these packages follow the directory conventions (or at least they should). For example, someapp would be installed in /opt/someapp, with one of its command being /opt/someapp/bin/foo, its configuration file would be in /etc/opt/someapp/foo.conf, and its log files in /var/opt/someapp/logs/foo.access.
First and foremost, this is going to depend solely on your architecture, and customs.
I for instance mount things like this under /mnt. I know people that create top level directories, and people who put this stuff in /home. It all depends on what you're comfortable with. There is no distinct standard on this anymore, the architecture of the system has changed, and you have varying views now, on things that used to be 'gospel'. Things like /usr/local or /opt/share, rpm or source...you get the drift.
Secondly, if you re-read through your link at pathname.com, you'll notice the paragraph under /media that states
Rationale
Historically there have been a number
of other different places used to
mount removeable media such as /cdrom,
/mnt or /mnt/cdrom. Placing the mount
points for all removeable media
directly in the root directory would
potentially result in a large number
of extra directories in /. Although
the use of subdirectories in /mnt as a
mount point has recently been common,
it conflicts with a much older
tradition of using /mnt directly as a
temporary mount point.
So personally, I advocate /mnt/windows or some iteration of that. It keeps the top level dir free, and is simple and intuitive. When I'm looking through or auditing a system, that's where I look for mounts right off the bat.
Best Answer
You make your own mount point directories. If you want to ask why, I can only point to the great answer by Wouter Verhelst.
Internal drives
/mntis a valid place to make your own if you like, and so is/./mntmay have been used for this purpose by some historical installation systems, as well as for removable media (before/media). It's still valid for you to do so, but the system itself is no longer supposed to set up anything in/mnt.I think it's reasonable to use /mnt if you might make multiple mount points. It makes it easy to see all of them together, and it's known as one of the locations people like to use. Some other people like to use
/Volumes- following the OS X system, or/vol. /data is common for a single mount point. /d/ is also used. /disk/ is almost certainly used by some, but may be distracting for storage which is not disk-based.If you use /mnt, I would also create /mnt/tmp. Then there will still be a convenient directory for temporary mounts, the original use of /mnt which FHS mentions.
Preferred mount points for internal HDDs
It's possible that manually creating mount points under
/mediais a bad idea on some common systems. Modern Linux OS's will create mount points for removable media automatically, and it's possible the structure they create would conflict, or simply appear inconsistent with your own. You don't say what your system is, but you may be interested in portable guidelines, especially if you're asking about FHS. Note this reasoning is similar to why the FHS says the OS must not populate /mnt.Mount point for system-wide USB disk
Network filesystems
It is sometimes recommended to mount network filesystems in a dedicated sub-directory e.g.
/n/host,/nfs/hostor/net/hostetc.For example, if you mount a network filesystem at /host and the network becomes unreachable,
ls /may hang when it tries to stat the network filesystem. This could be undesirable and frustrating, at a time when you are already becoming frustrated.