> This conclusion is not really supported by the facts.
Oh yes, it is. I have to wholeheartedly disagree with almost everything you've said, I'm afraid.
STUN requires a centralized outside server. As I said, by now there are better libraries that didn't exist ten years ago, but even they fail often. NATs behave very differently form implementation to implementation, some don't even get UPnP right, and it takes a lot of resources to get p2p reliable without special user interaction (e.g. with their home router) and without any server outside. AFAIK, there not no single library or method that works reliably without a server outside of the NAT. Also don't forget that I was talking about why decentralized p2p didn't take off, so we're talking about a of 1996-2010 not about now.
Adoption of technology does not work the way you describe, it works similarly to language change. It doesn't have much to do with resources of companies. Here is how it works in reality:
1.) If there is already an easy to use service that covers the functionality, new ones will likely fail. (Just like possible word compositions are often blocked when there is already a word for sth.)
2.) If end users cannot get it running within a few seconds, the technology will likely fail. (If it is intended for a mass market, I'm not talking about specialized tools or b2b software, of course.)
Decentralized p2p failed because of 1.) and 2.), and the reason for 2.) was primarily the lack of a cross-platform, reliable way to punch holes through NATs.
All of the examples you give fall under 1.) or 2.) respectively. On the other hand, Bitcoin is a typical example of p2p that satisfies both conditions, and that's why it was successful.
But there are are more conditions (though not the ones you suggest). One major factor was also that for an ISP, it's most desirable not to see strange server traffic from their ordinary, non-business end-consumers. So even if you succeed with NAT and complicated network topology issues, ISPs might still mess with the traffic or even block it. In fact, some infamous ISPs even disallowed running servers at any non-standard ports for some time, and used other methods to limit the Internet to passive web consumation for their customers. My ISP in the late 90s, for example, used PPP over ADSL for no technical reason, and switched off the connection once a day for no technical reason other than making it a bit harder to get a continuous server to work. And let's also not forget that most consumers nowadays are behind ADSL, where upload speed is usually limited 10 times less than download speed. That alone makes p2p harder.
Again, all mostly technical reasons. By the way, the Linux Desktop is also not successful for mostly technical reasons, contrary to what you claim. First, there is the application barrier maintained by commercial companies - a technical issue that could easily be overcome if besaid companies would work on interoperability standards (they do the opposite, of course). Second, there are numerous issues with usability on Linux that will never be resolved, because they would require everyone in the Linux world to pull on the same string at the same time. But these issues are still technical in the sense that there would be technical solutions to them, if there was some sort of "benevolent Linux dictator" who could force every programmer to use a given API like Apple forces their developers.