/srv will continue to be ignored just as /opt and other one-offs are ignored. Reason being that they duplicate existing functionality, in this case under /var, /usr, or /usr/local. What /srv/ really stands for is NIH.
/srv is a bit questionable to me. Basically it's another /var. I always used directories like /var/local and /var/share (sambd and nfs shares). However, I am understanding the FHS crew wants to freeze the /var filesystem because it was getting too crazy with all kinds of stuff being placed under /var, and the likelihood of conflicts was getting high.
But I think /srv actually makes more sense as /var is often on separate disks because /var/lib/ gets very IO heavy.
I also prefer having packages with their own hierarchies under /opt, rather than /usr/local/<package> -- in general stuff under /usr/local should put their binaries in /usr/local/bin -- their manpages under /usr/local/share/man, headers and libraries in the corresponding places -- so that I don't have to mess with my PATH settings to be able to run a command, look up a man page or link against a library.
Sometimes software isn't packaged for use on a posix-like system -- and then I might have to do some dancing to get it to work -- I usually prefer having such programs under /opt/<program-version>.
I do have another folder under local: /usr/local/xstow -- so I can easily compile packages and manage different versions under /usr/local/xstow/package-x.y.z.
Especially some commercial and proprietary software that runs on Windows, HP-UX, SCO, AIX, Solaris and Linux tends to go the "easy way" of packaging and just put stuff in one place on every system.
This is merely a convention, not set into the 2.3 standard apart from the naming 'tertiary hierarchy' otherwise implying this, but it's nonetheless a widespread enough convention — notably in use by every single configure/make/make install (and more) source distribution out there, whose default PREFIX is /usr/local — that we can expect it to be standard behavior.
Similarly for /srv
Remember: the filesystem hierarchy and your underlying storage don't have to correspond.
There are other tricks which can be accomplished by union mounts or similar foolishness.
Most vendor supplied software is by tradition installed in /opt, for which we should be forever thankful because most software vendor wouldn't recognize a properly packaged piece of software even if it jumped up and bit them in their arse.
Oracle was in the early days installed in /u01 with data- and log-files spread out over separate disks with mountpoints normally named /u02,/u03 and so forth. It isn't uncommon that this naming convention still partially is used on oracle installations.
Today oracle published a standard called Optimal Flexible Architecture (OFA) where all oracle products should be installed under a common top-level directory.
The oracle universal installer isn't as horrible as it used to be but it isn't a well behaved rpm/dep installation either, at least it claims to have heard about LSB-directory structure even if it doesn't follow it very well.