After all there are several layers of differences between Skype and Nextcloud Talk and possible reasons why Nextcloud Talk indeed needs some manual/additional install steps to work over www like Skype, WhatsApp and comparable other solutions.
Open-source WebRTC
Nextcloud Talk is based on the open-source WebRTC standard. This means basically any system/software can be a client/peer, as long as it fulfills the standards definitions/API, although in the first place it was created for web browsers and is mostly used there, AFAIK. While this provides a great flexibility, as no one is forced to use a special client and one can even build it’s own, on the other hand it means that you have a wide range of different specific implementations. I have no detailed insights here, but I guess it is always an issue that certain browsers handle the connections slightly different (in a degree of details, that might be outside of the standards definitions, wanted or unwanted). Also one cannot just add a feature that is not part of the WebRTC standard, at least not without adding e.g. a second API/protocol outside of the WebRTC connection.
- Skype and other closed solutions can tune their protocol and client software more tight and “freely” add or remove features etc. In combination with a horde of well payed developers and many years of development, I guess a more “smooth” and complete seeming solution is possible.
But: The downside is, that you are bound to the clients offered by Skype and that you need to trust those in security questions (How transparent is MS about security wholes within Skype?) and the company/Microsoft about their intentions and use of e.g. collected usage data etc.
Peer-to-Peer
WebRTC is in the first place a Peer-to-Peer standard, which means that no 3rd relay/server is involved in the connection that could listen to what you are talking. This also makes sense for an open standard like this, since API definitions simply cannot provide/assure any 3rd party relay/server being available 
. This brings the limitations in combination in combination with NAT/firewall/www connections, where you then need additional software to solve. TURN server like coturn generally work fine here, but again their are not build for WebRTC only, thus provide a rich set of settings and features to chose, where some might be needed for WebRTC and others not, again some for the specific Nextcloud Talk implementations, others not. So the “maybe most-compatible” default settings of e.g. coturn do not work with Nextcloud Talk.
- As mentioned by the others (great, since I have no idea how Skype works, just assumed it is no real P2P), Skype has an integrated solution for this and own/MS server are included.
I am sometimes thinking if it would be beneficial to bundle Talk+STUN+TURN, like e.g. Pi-hole integrated dnsmasq into their FTL service, to avoid some manual config file adjustments, automated the secret exchange etc. On the other hand this means always additional effort for maintaining the fork or bundle (depending on how far the integration should go), talking developers capacity from concentrating on the clients. I think a good step by step guide (as hopefully above) should be working for everyone who already managed to setup an own Nextcloud server, right? 
Browsers
Jep, Opera (I guess chromium based browsers in general) need to allow WebRTC connections on “non standard public and/or private” networks, which ever standard is meant here. While Browsers are strongly rated and reviewed in terms of security, thus are forced to add such settings (which is great from my point of view), Skype will never ask, if you trust the network you are currently connected to. Security vs comfort… However I think marking one switch is not too hard . Hmm with Firefox it is not that easy?
€: Hmm: https://webrtc.org/web-apis/firefox/
We don’t have TURN support yet, but we plan to support it soon.
But the page seems outdated… Also not sure if this applies in case of Nextcloud Talk.