The closer to production the more the servers should be identical. The purpose of that is to make sure the final installation will be free of unanticipated problems, i.e. the "works for me" syndrome. However, the closer to development, we need more freedom to experiment. So I would say that the entire set of platforms don't need to be identical, and in fact really can't be.
One of the things you are doing right is using an automated build script. Whether it's ANT or Maven isn't as important as the fact that the application is compiled and the JARs are assembled the same way every time. This will help avoid a number of issues.
The pain point you mentioned--bugs due to differences in application servers--is a double-edged sword. The more application servers your app is exposed to, the more portable it will be once you've ironed out the problems. On the other hand, unless you are building an application that your customers will be free to install on their own app servers the extra work needed for portability just eats up time that you could spend fixing other, arguably more important, bugs.
It's a sad fact of life that sometimes our choice of application server is constrained by our client's IT policies. "Thou shalt use IBM or Oracle, yea and verily" If that is the case, then at least everything from the test server on should be using the same application server as production. In development land, you may want to standardize on only one of the alternative application servers. If you are moving to Maven (as it sounds like you are), then Jetty is a natural match. Maven has a preference for Jetty, so running the application in the app server is as simple as typing
mvn jetty:run (see this article).
Essentially, you'll want to minimize the number of things that can go wrong. If you can catch the majority of the incompatibility issues at the test stage, you are way ahead of the game. Staging should be pretty much lock step with production, as it is going to be your last chance at finding install problems that might bite you in production. The same hardening processes you have to use in production should also be used on staging. Testing should use the same technology stack that will be used on both staging and production, but does not need to be kept in lock step. It will be your first opportunity to find problems due to upgrading the server or libraries you are using.