An unnoticed side-effect of implementing rich internet application platforms -- whether they're AJAX or anything else -- is that this 'client-service' architecture eliminates the need for an application server to connect the Web client to back-end resources.
First of all, AJAX -- a newly coined acronym describing technology invented in late the 90's -- does not set out to replace the application server. In fact, one of its earliest application, Outlook Web Access, makes calls to an application server, i.e. Exchange. The client side has certainly been made more stateful, however the idea is to make the UI more responsive, rather than migrating the business logic over.
Secondly, if an application server easily found itself redundant when the client side deploys AJAX, the question should be -- why do we need that app server in the first place? I have seen many simple web-based applications employing as many application server buzzwords as you can find, mostly in J2EE or .NET land, to achieve something that can be written in a few lines of PHP or Python. Keep it simple or stupid, AJAX or not.
Personally I found developing AJAX applications a tad easier than the traditional web applications, where a single translation in the application server might need to be translated to multiple page views with states carrying over from one page to the next. Now the navigation can be done via requesting state-less XML data from the application server, the whole state can be cached on the client side, and the changes can be flushed to the application server/database via one single call over HTTP.
Less state in the app server = less code = better scalability = good thing.