I've done a good bit of Servlet development over the last couple of years. I've generally found Servlet to be pretty good to work with. I feel Servlet is about the best part of J2EE.
The thing about Servlet was that when it came out in the late 1990s it had to compete for market share and developer mind share. They had to convince people to start using it. So Servlet does things that are developer friendly. For example within Servlet development the programmer has access to the full JDK. So you can do stuff like launch threads and use synchronized methods or go to the file system. This is great and I've developed a new appreciation for the richness of the Java5 JDK.
Also with JSP/Servlet it is fast and easy for a new user to get running quickly. Tomcat and the JDK are free to download. From a standing start you can get a hello world page up quickly in just a few minutes. The web.xml can be minimal and mostly stays out of the developer's way.
With Servlet the container helps the developer and adds useful functions like the HttpSession. What I really like about HttpSession is the session attributes. This is a delightful little feature. You just start using them by name with like session.setAttribute() and read them back somewhere else with session.getAttribute(). This is very useful to pass stuff around between different functions. I like it because it reminds me of Python where you just start using stuff and don't have to worry about it being declared or strongly typed. It's very convenient and developer friendly. The fast, convenient and easy to use session attributes are an example of how Servlet is designed to be developer friendly.
Unfortunately the Servlet experience is not typical of working with J2EE. I suspect with many of the other J2EE components like EJB the developer community was considered captive. Since they didn't have to compete for developer mind share they didn't spend very much time or effort thinking about the developer experience, developer productivity or being developer friendly.
