Pretty much no client or server uses it that way though. The UID extension is more or less required these days.
But IMAP is pretty twisted in other ways too. IMAP is _not_ a request-response protocol like you might think from other protocols. It looks like it at first because you can say things like (from memory, not the real protocol):
> cmd1 LIST (here cmd1 is a request/response identifier chosen by the client; the server sends responses prefixed by this identifier)
< cmd1 LIST RESPONSE...
But you can also multiplex many simultaneous commands like
> cmd1 LIST folder1
> cmd2 LIST folder2
> cmd3 LIST folder3
< cmd3 LIST folder3 RESPONSE...
< cmd1 LIST folder1 RESPONSE...
< cmd2 LIST folder2 RESPONSE...
(note that they can come out of order)
But it gets weirder because you can receive _unsolicited_ responses. Sometimes you want that like
> cmd1 WATCH folder1 (starts a watch which may have responses but not immediately)
> (do other stuff)
< * NEW MESSAGE folder1 DATA... (some time later)
< * FLAGS CHANGE folder1 DATA... (much more time later)
(the * means that you didn't ask for this so it's not prefixed by an ID that you gave) Here it's sort of solicited or at least something you did on purpose, but there are other more complicated cases where you'll receive data that you never asked for. Again from loose memory but an example might be
> cmd1 OPEN folder1
> (do stuff with folder1)
(much later)
< * CLOSING folder1 WAS DELETED
That means that your client needs to always be listening for data on the socket and reading it out even if the client is sitting in the background, and that if you send a command you might receive responses to other previous or unsolicited commands before the response to the command you just sent.
It's a cool way to do what it wants to do for GUI clients in particular because IMAP and GUIs have the same event-oriented model. But it makes implementing IMAP as a library a little more difficult because you need bidirectional hooks into the containing application. And you can't easily just have a `if POP3 then... else if IMAP4 then...` abstraction layer without some work to make it happen. Heck even just having a function that returns the list of messages requires a background thread and a little bit of lying about what's happening underneath. Leaving data on the socket unconsumed can get you disconnected by keepalive checks so the background task is required if you want to avoid that (which by observing mail.app it seems to just accept the disconnection and reconnect when it happens). Python has an imap library in the stdlib which "avoids" this by being so low-level that it sidesteps some of the issues by making you implement request/response on top of it, and its model also makes perfect IDLE implementation difficult (maybe impossible? but I didn't put enough time into it to prove this).
Because of the complication many GUI clients don't actually support the liveness built in to the protocol. They just ignore any reponses they didn't ask for, don't use WATCH/IDLE, and do the 15 minute polling cycle as if they were POP3. The protocol has all of the tools to have the liveness of Google Docs but I'm not aware of any GUIs that use it right.