Depends on what your application needs. Tomcat is mostly just a servlet container, while JBoss, Websphere, and the others provide full Java EE support (usually plus additional platform-specific features above and beyond the Java EE spec).
For many applications, a servlet container is sufficient. Especially since you can get a lot of Java EE-like features by just bundling the appropriate libraries as part of your webapp. But sometimes you need this-or-that feature that is only readily available on one of the full-scale application servers.
That said, using a full Java EE server when all you really need is a servlet container does strike me as a fairly foolish thing to do. As a general rule I always start with Tomcat, and only switch to something like JBoss once I've identified a need for something that Tomcat can't provide (doesn't happen often).
It's really trivial to take a webapp that runs on Tomcat and make it run on JBoss, so there's no reason to jump straight to the more complex platform and no real penalty if you decide to do so later on in the game.
Regarding the specific points raised in the blog article:
You need an application container that supports EJBs
He's right, you don't need this. There are popular frameworks like Spring which provide the same sort of functionality as EJBs. You can do just as well with one as with another, and it's generally not the case that you will use both at the same time.
Optimized application servers optimize hardware
No comment. Personally I'm of the opinion that unless your webapp is doing heavy multimedia processing or similar tasks then modern hardware has gotten to the point that it is more than fast enough to run whatever your app may be, even without any special optimization. That's why virtualization is such a big deal. A single server is now way too powerful to dedicate just to a single site, so we carve it up into several virtual servers each running their own site because otherwise all that computing power just goes to waste.
Two-phase commit is serious
Again I don't disagree with the blog post. Two-phase commit is not serious, unless you happen to need it. And I've never once needed it. A database with optimistic transactions and rollback has been sufficient for every project I've ever worked on.
Manageability
In my experience as a developer, JBoss is far less "manageable" than Tomcat. It is just ridiculously difficult to configure. Granted that's not the same type of manageability the article is referring to, but it's still worth noting. Other than that, Java EE containers will generally have far more built-in features surrounding server management, but there are also plenty of third-party tools that you can use to get similar features out of Tomcat (or any other flavor of server).
Clustering supports scalability, performance, and availability
Tomcat supports clustering, and is no less scalable than the other platforms. In fact, JBoss runs on top of Tomcat, so obviously there is nothing about Tomcat that inherently prevents it from scaling or makes it unsuitable for use as an enterprise-level platform.
