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)
but then you have to support different servers which means a ton of combinations to test and debug - IMAP is a standard protocol
as it the goal for JMAP (http://jmap.io/). and the Gmail-API is a semi-standard protocol as well. dovecot supporting one or both will help them become more standardized.
and despite being a standard, there is quite a bit of variability among IMAP servers. i see new IMAP servers (mostly on the windows side) that are broken in different ways every week.
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.
again: you would have a dozen of different roundcubes
no, you'd have one roundcube, with a dependency on a new standardized JSON mail access protocol.
both JMAP and gmail-API aim to eliminate some of the pain involved in using IMAP for webmail. roundcube *could* try and create a new standard, or go with a proprietary protocol, but why reinvent the wheel? part of the idea being redoing roundcube is to take advantage of developments that have come up since the project was started - these two new access protocols are two such recent developments.
the more the backend components are separated, the easier is it for everyone to find optimal ways to run it in their environment
flexible != easy what most people expect is "unpack a tarball in a webhost, enter username and password, done" - you can say that you don't care for that expectation and that these users are no longer you target, that may be fine from your sie but at the sam emoment would mean lose a large part of the userbase
it's completely possible to distribute a version of roundcube that just works if you untar it, while still allowing people to choose to do more advanced things with it (by disabling/replacing/overriding stock components/config). such a thing would not be a unique concept in the software world.