Easy to get a server running: just install tomcat or jetty on your production machine, sftp the war file and it automatically deploys.
Init.d scripts are tricky to write and get right, by using a tested script from a distro things tend to work out of the box.
Monitoring -- easy to hook in some monitoring script that can reboot tomcat or jetty should the server stop responding.
Techops generally know how to deploy a .war file -- I would not feel comfortable telling someone to learn lisp just to deploy a webapp.
pretty interesting with swank -- need to look into that.
Deployment. If you have a procedure in place that handles versions of the server side code using .war files then you can simply give the sysadmins a new war to deploy and that will be that.
It's convenient because it is just a single file, if you want to roll back just move the old war file in to place, do 10 seconds of housekeeping and you're back up. Not that anybody ever had to revert to a previous version of their production code, of course. But in that hypothetical case...
Another advantage would be if you've automated your deployment across a large number of servers using this method. Update the master, send the signal to 'fetch and deploy' to the rest of your servers and that's it.
Another way to do it is just load the swank jar on your server (the server side of slime). In your server startup, include a call to (start-swank). Then you can connect via slime whenever you want using M-x slime-connect, and you don't need emacs + screen to stay running.
I've only learned the JVM as part of learning clojure. What advantages would a .war provide?