> - There's functionality that you basically shouldn't use; the big one is search. Even the specs more or less say "good luck using this".
Message sequence numbers. Every folder in IMAP has its emails numbered from 1-N, with no holes, so if you delete a message, everything after it has its message sequence number decremented to close the hole. Except IMAP is multiclient, and the message can be deleted by other connections than the one you're currently on. But the server is only allowed to tell you about message deletions at certain points, so now the server has to keep essentially per-client message sequence number state and carefully make sure that everyone is kept in sync... and it's a recipe for disasters in practice. Any sane client will instead use UIDs for everything (and any sane server will implement all the UID extensions to let UIDs be used for everything).
The other fun corner case I recall is that IMAP part numbering is a little unclear what happens around body parts of content-type message/rfc822. So I crafted a message that had a multipart/mixed with one leg being a message/rfc822 whose body was a message/rfc822, and tested the output on all 4 IMAP server implementations I had accounts on at the time to see how they handled the part numbering. I got back 4 different results. None of them were considered correct by the IMAP mailing list discussion on the experiment.
> I think this all means probably every non-web email client treats IMAP like POP and keeps its own store.
The distinction I would use is thin client versus thick client. Most clients like Outlook or Thunderbird are thick clients, which need to maintain their own local database for other reasons (like supporting offline mode or having database features not necessarily supported by an IMAP server, like arbitrary tagging). If you've got a local database, it's much saner to use IMAP essentially as a database synchronization protocol rather than trying to build a second implementation of all of your features on top of IMAP's native features, especially given that IMAP server implementation of these features is generally questionable at best.
IMAP was originally designed, it seems to me, to make thin clients easy to write (I can see how something like pine would be a very thin veneer over the protocol itself). But it's been clear over the past few decades that most clients are of the thick variety; things like QRESYNC and CONDSTORE were added to make the database synchronization steps a lot easier.
> Any sane client will instead use UIDs for everything
Yes! Since last year there's the experimental UIDONLY extension that allows clients & servers to operate entirely without message sequence numbers. Saves quite a bit of accounting and possibly memory (for large mailboxes). It's a bit surprising the RFC so recent.
> [... thick vs thin clients ...]
For some programmatic email access, IMAP seems quite easy to use. Just write a programmer-readable line of text as command (eg fetch/search/store/etc) and parse the response lines (that's a bit trickier in many cases, probably needing a library, but you may be able to get away without it some of the time) and you're done.
About thick clients: Storage capacity is growing much harder than my email, also on mobile. I would be fine with thick clients that sync all messages. Allows for simpler protocols and simpler implementations. An email access protocol is then not much more than a two-way sync of email message files and associated "dynamic data" like flags/keywords.
But IMAP and JMAP are doing many things at once: synchronization for thick clients, and online access for thin clients. JMAP is specifically targeting the web (thin clients), so what was old is new again (although base IMAP isn't too helpful to (web-based) thin clients either).