But the hi-fi "elite" is exactly what Oracle is trying to avoid, the all in a box solution is to guaranteed to work, using a hi-fi analogy is, on the face of it an error as all you're dealing with is sound going from A to B so it should be simple, but even that isn't true in the hi-fi world, appropriate levels of pre-amp, do you use coax or digital, internal or external D2A, bi-wire speakers and that's before we start getting into surround sound, SACD/DAT etc. etc. etc. building a true hi-fi system was far more complex than popping down to Currys and picking out what looked nice, there were only "broad" standards.
Your point however is a valid one, if there were standards that everybody agreed then you could mix and match, but, apart from a few well-known (and old) standards, people don't get together in a room, design it all then start building, they prototype it, then define a standard based on their build, then they propose a new standard (after building it) to fix and enhance what they ahve built, this is because the place this technology is used is a comercial one and you have to have products out there as fast as possible.
The four network standards you mention have had huge numbers of revisions, taking FTP for example RFC114 was the original proposal (oddly enough older than the network to support it), but since then it's gone through versions 1,2,2.1,3,3.1,4,5,5.1 each of these have had multiple RFCs associated and of course it is still developing, we have proposals (pre FRC) that handle new char sets, encryption, hashing etc.
So, you have a valid question, but it's based on a false assumption that there are simple (single) standards all developed and agreed which a supplier can stick to, in reality the goalposts are moving all the time, and of course on top of that is the proprietry stuff like load-balancing communication (VRRP and open standard, HSRP cisco, ESRP extreme, FSRP foundstone, there's a great story in there about manufacturers pissing contests if you want to do some research), the same is true for routing protocols, auto negotiation etc. the history of Ethernet and what was lumped on top of it is actually a great read, I suspect there's a "Biography of Network" book out there, if not it would probably be a good one to write, full of intrigue, back-biting and scandal (OK, maybe just geeky but surprising).
In summary, limit the hardware combinations and it's more likely to "just work" because you have less unknowns in the mix (like a Mac with very few combinations compared to Windows which is expected to work on any hardware, you've got no-one to complain to when your Hackintosh has a driver issue), and assuming you make good choices on the initial hardware i.e. it can do the job then no issue.
In addition, having a single vendor for your stack prevents the (all too often) blame game when e.g. the supplier of storage blames the supplier of server (and vice versa) for issues such as performance (I can't understate how much of an impact this can be).