There's nothing keeping you from running a separate web server and then proxying requests to Node using HTTP. Why is it a problem that you do this using HTTP? What alternative protocol would be so much better? FastCGI isn't really that different (each have their pros and cons) and CGI has obvious problems...
WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).
All they say is that no matter how much you use you will never have to pay for it (at least that's how I read it). Obviously they can't guarantee that they will be able to offer you an unlimited amount of inbound bandwidth (there is no such thing!). Do note that they make no guarantees about the speed of your inbound connection either.
The same goes for other things, of course. You can't necessarily get unlimited outbound bandwidth and you can't buy an unlimited number of servers from them and so on... Sure, those limits (both quality and availability) aren't stated explicitly, but I still think it's fair to say that "whatever amount of inbound traffic you use we won't charge you for it". In extreme cases they will need to do something, but there are other options. There's a certain value in keeping things simple and flexible.
I do agree, though, that hiding (important) limits is generally not a good thing to do.
WSGI applications can use a built-in HTTP server too (or FastCGI or ...). Node has an internal interface (similar to WSGI) for handing over requests to the web application and so on. That's not fundamentally different from WSGI. The main difference is that WSGI is a standard API, so there are several "WSGI servers" implementing the same thing (each of them similar to Node in some sense).