I wouldn't say "broken", but more "stuck in its ways" since it's a huge standard, used by everyone, and as a result, network effects (literally everyone online uses email) keep it from being improved in any way.
Since everyone's using this standard, the only way forward is to either jettison the whole lot and start fresh (network effect means this will never happen), or to wrap it, maintain compatibility, and slowly get your wrapper accepted (which is at least possible in this universe).
1. IMAP's base spec (RFC 3501 [1]) offloads implementation on the client rather than the server. For example, the client must be able to parse the IMAP protocol, it must have be able to create threads by searching through emails, it needs to implement the logic for syncing, ... etc.
2. There are many IMAP extensions to patch the issues of the original spec [2], but implementation of these extensions across email providers is fragmented, and implementing them both server and client is plenty of work.
This is an attempt at a modern, cohesive API for email.
It's also hairy, slow, and a bit buggy.
Some concrete issues: https://gist.github.com/mscdex/5329227
Since everyone's using this standard, the only way forward is to either jettison the whole lot and start fresh (network effect means this will never happen), or to wrap it, maintain compatibility, and slowly get your wrapper accepted (which is at least possible in this universe).