In a pure pedantic sense, the only thing that can be deployed as a webapp to a
J2EE server is a WAR or EAR file. EARs don't apply to
Tomcat, so nothing more will be said about them.
In a practical sense, it is not uncommon for J2EE webapp servers to unpack WARs that have been deployed to them into some server-internal location. In the case of Tomcat, this unpacking is optional, but enabled by default. Furthermore, Tomcat can run WARs that were never packed to begin with.
I've never seen any claims of greater performance one way or another, but one advantage that you do get from working with unpacked WARs is that if you want to tinker with them "on the fly", it's a lot easier to update files in the exploded WAR directory than it is to build and deploy an entire new WAR. Especially since recent-vintage Tomcats have had a tendency to run out of PermGen space when apps are re-deployed.
I take advantage of the "never-packed" functionality to speed up my development process a smidgen. By setting my webapp context root to the target directory in my
IDE project, all I have to do is run the compile/copy phases of the webapp build and skip the actual "pack into a WAR file" phase. It's not that the packing phase takes very long, but a few seconds here and there do add up.