One could also ask, why use anything else when Axis is around for a long time as [sort of] a standard web service tool? But I do agree with you purely based on personal choice and other observations.
My problems with Axis:
1.
EJB based endpoints are difficult to implement
2. It doesn't follow the JAX-RPC packaging structure
For more insights, see
here.
On the other hand,many tools that support web service, use Axis behind the scene. For example, Vitria, an integration tool, uses Axis. Informatica PowerCenter, an ETL and data integration tool, uses Axis. Sometimes, to interoperate with these tools, you have to use Axis. In one of my projects, we wanted to invoke a web service on Vitria from WebSphere but we had an XML type that was only supported in Axis. We couldn't use WebSphere JAX-RPC implementation.
When should you choose Axis?
1. If you want a light weight web service container
2. When you want to or have to package the web service container with your application. Remember, you can package Axis with your web app and deploy it in [say] WebSphere. This way, your code won't use WebSphere web service container, it will use Axis
Metro and Glassfish are great tools. In fact, that is what I use when I am not bound by my client's requirement to use something else. It's just that Axis got more attention as the early entrant in the market. Plus, there is a ton of 'how to' available on using Eclipse + Axis.
