> - 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.