I would be much more uncomfortable running on uWSGI than on net/http. As far as I can tell (https://github.com/unbit/uwsgi/blob/master/plugins/go/src/uw...) Go's uWSGI implementation is just a small wrapper over C code inside a dll.
It's not portable (support for cgo on Windows is extremely sketchy).
It also goes against common sense. Any code you can write in C, you can write in Go, except it'll be easier (Go is garbage collected, has built-in arrays, strings, hash tables etc.) and there's drastically smaller chance Go will have a security issues due to memory over-write.
It duplicates lots of net/http functionality.
net/http is well documented, well tested, reviewed by extremely knowledgeable people.
Most importantly, it is being used in production by me and many other people.
Finally, net/http gave me everything I needed to write my web applications. Before I would even considering using uWSGI (or anything else) someone would have to explain what exactly does it provide that is so indispensable for writing web apps.
Sadly me (and a lot of other people) need a lot more.
That is why the uWSGI project exists. Things like logging, clustering, statistics, multi protocol support, alarms, time events, request routing and blah blah are added to your app for free (and the funny thing is that you can tune lot of internals without rebuilding your app).
Obviously if not having windows support is a too much high price for you the discussion ends here :)
My point? These things came way before node.js, so no, node.js isn't the only one with a built in webserver.
The difference is node.js has a rather performant built in webserver (still, exeperience shows that a properly tuned gevent or netty beats a properly tuned node.js). The idea is that instead of spending time tuning these things, you can just wrap it in a uWSGI container, and let better tuned-out-of-the-box servers like nginx handle the webserving
Though you have to look at the package api yourself to decide whether it's running directly or not.