When you type a URL into a browser's navigation bar - or use any other URL-based reference to a website for that matter - the URL is parsed into its components. One of those components is the server/domain name. This name is then looked up in the "telephone book" of the Internet: DNS.
DNS entries only contain IP addresses, not port numbers. So if you make a request to a a server, the port name selected will be 80 for HTTP requests or 443 if it's an HTTPS request. If you want any other port, you must explicitly ask for it using the :port#" part of the URL. That's a function of the client (your browser), regardless of how the server was configured.
In general, complex websites will use something like Apache as the master dispatcher for all incoming URL requests. Apache will then analyze the URL and send it to a suitable handler. For Tomcat requests, that means that it will route the request via mod_proxy or something similar from the Apache server to the Tomcat server.
Although it might seem simpler to route directly to Tomcat, there are reasons why the Apache-to-Tomcat approach is preferable.
One of them is port conflicts. Since only one app can hold a port for listening, if Apache holds Port 80, Tomcat can't have it.
Another is security. On many systems, only root applications can open ports numbered below 4096. Apache can start as root and then switch to a less-privileged identity to protect itself and the system, allowing it the benefits of being able to listen on port 80 yet run unprivileged. Tomcat cannot do that. It would have to shed its write-once/run-anywhere abilities to do so, since OS-specific functions are required to do that.
Servlets ARE resource-intensive compared to say, PHP. However, bypassing Apache won't make them any less resource intensive. The whole point of servlets - and
J2EE - is to be able to do resource-intensive processing.