I don't know, if I have understood Thomas' idea correctly, but IMHO client-server application means that server part (back-end) listens on the server ergo is a daemon which means You no longer have to initiate IMAP connection, login etc on every refresh You make in browser. And the client is the client (browser, desktop client, mobile app, your something script somewhere etc) which speaks to the server using the defined protocol.
i'm pretty sure thomas didn't mean that and instead meant a stateless JSON protocol with most of the logic in the client application and the server doing less work overall.
apart from the mail interactions, a basic webmail server wouldn't have to do too much apart from getting and saving user preferences. a more advanced setup might require proxying/converting requests to/from CalDAV and CardDAV servers. For a CalDAV proxy, PHP would be a very good language choice as the sabre/dav library handles a lot of the really heinous bits of the ICS format for you.
the mail interactions could be offloaded to a completely different project. Dovecot has announced gmail-api support, and has also floated the idea of supporting JMAP. If the rouncube client can just call a standard JSON API to get mail from the imap server, then roundcube doesn't need to worry about that portion at all (which would be a very good thing - indexing/caching/etc would all be handled by the imap server)
even if dovecot/courier/etc don't directly support any JSON APIs, a separate daemon could be produced to do the proxying/conversion. it need not be part of the roundcube project (there's already an IMAP->JMAP gateway/proxy https://github.com/jmapio/jmap-perl/blob/master/bin/server.pl). for hosting situations where only php is allowed, a non-daemonized version proxy layer could be written in php.
plugins would not neccessarily need to conform to any protocol standard, they'd just need to come with some client js code and some type of server code that could get/set JSON data as the plugin needed.
ie, you have a javascript client calling:
https://mydomain/api/mail # mail API https://mydomain/api/settings # roundcube user settings https://mydomain/api/calendar # CalDAV proxy https://mydomain/api/contacts # CardDAV proxy https://mydomain/api/plugin/myplugin # myplugin
it's easy to reverse proxy content in a webserver or load balancer, so any large hosting company could proxy the different API services as needed. a smaller host might only need to proxy api/mail (ie, if dovecot were providing the mail api services)
the more the backend components are separated, the easier is it for everyone to find optimal ways to run it in their environment.