My quick opinions on this:
From experience, I want to avoid adding lots of interfaces directly to the Drillbit. For applications other than other Drillbits, I'd like to constrain that all to the UserAPI/RPC interface. The only other interface that I see being available is JMX for metrics. As such, my preference would be that what other non-query information that the web gui need be also sent through the Drillbit API. I think this will keep things simple and always ensure that cross version and cross language compatibility are managed. This also means that later managing the implementation of security is much simpler. Given that, if you need more functionality from the Drillbit it would be best to add additional request/response types and message types to the User API.
As far as server infrastructures go, I've actually really liked some projects I've worked on recently where the server component only exposes a REST JSON API and static asset serving. I've used both Jersey and Resteasy in that way with much success. If someone wanted to do something else, I've actually found JSF+Primefaces reasonably competent albeit irritating and not very rest friendly (and slow/big).
My other thought would be that if we want to have a server component, that we try to stick to servlet APIs for the functionality. Easy starting of Jetty is great if you don't already have infrastructure in place. However, productionizing many separate Jetty instances can be a real pain, especially if you have another web container that you utilize (like Weblogic or Glassfish). Since our requirements should be pretty sparse, it would be great if we didn't force people to use one container. (To me this just means that we separate out the WAR application from the running of it within embedded jetty or tomcat.)
One other question here is whether the server component should even be in Java. I know a lot of people like Python & Django for these types of applications and if we commit to constraining interaction to the protobuf user api, the person that will actually spend a lot of time writing this component should feel comfortable using what makes the most sense given the requirements.