At least half of the blame should be not on them. IMAP doesn't know a thing about what happened to email in last 10 years (few minor exceptions apply).
They're merely implementing their own means to access email in convenient and modern way. Say, IMAP has no labels[1] or contacts[2] (and many other things) - there are proprietary extensions, MS Exchange being the most famous one, but they're... proprietary. And given that proprietary implementations differ, it makes sense to create an unifying wrapper.
And JS apps and web services are just an approach that's trendy today. Personally, I don't like it either, but can't blame for going with the flow. Especially since it's a business (and going against the flow has costs, both in development and adoption), not a private project where one can do things in a way that just feels right, ignoring anything else.
I believe it would absolutely make sense to bundle the "sync engine" within the mail client, though, to make it standalone. But I understand it's done this way just because there was only the engine (as a service, not a library) at the beginning.
IMAP actually does have labels. They are called flags. Servers tend to not implement them well at all (sometimes allowing only a handful to exist, and almost never keeping an index for that metadata, meaning that searches by flag are either slow or often not even allowed :/), but that is not the fault of IMAP.
And, FWIW, search defined virtual folder is a client concept and would be trivially implemented over IMAP's incredibly powerful (and I believe I remember being even extensible) search commands, if only IMAP servers tended to provide the right kinds of index to make such queries fast. (I know this, as I was working on a highly scalable and very efficient IMAP server a few years ago that I had to force myself to stop working on as it was too much of a distraction from the things in life that are actually capable of putting food on the table.)
Mark Crispin was actually pretty-damned prescient when it came to IMAP: he believed that client operations should be offloaded to a server that would have much more disk space and CPU than the client, which is exactly the model everyone reaches for today, and thereby designed a thin client protocol that had asynchronous updates baked into its core. A few years ago, he passed away: here is what I wrote at the time about his mission for IMAP and history on the project.
Really, the only thing in IMAP to actively dislike is how the thin client view requires the server to have a "dense" (here I mean the mathematics term, not from the technical spec) numbering of messages the client is modeling in its view (this is the reason opening a large mailbox via Zimbra takes forever, and why many IMAP servers have dumb global locks), but I have come up with some techniques that should allow me to handle that with minimal overhead. Otherwise, with some of the modern extensions in place (QRESYNC, for example), IMAP is pretty damned awesome.
IIRC, IMAP flags/keywords were limited compared to folders (and a message can't belong to multiple folders). But maybe I got a wrong idea when I read the RFCs...
I would need a more concrete complaint to tell you why you are probably wrong here. The only thing I know of that tends to cause people to balk at flags is the frustrating idea that the name of the flag for some reason has to be the same as the name shown to the user, so the inability to rename flags or even use special characters causes people to give up on them... but you should treat them as opaque database tokens, not user-visible metadata, and map them to names. There was then an extension being worked on to store high-level names in the IMAP metadata store, but I don't know if it got completed (I havent paid much attention since Mark Crispin passed away: I felt like he was one of the few people keeping IMAP from losing its way, so I am highly concerned that I'm going to read through the mailing list and find people frantically pushing through all the stuff he had vetoed). But like, adding your own "documented but non-standard" blob to IMAP's metadata would still be worlds better than throwing away the entire protocol and starting over again from scratch :/. Honestly, I think the core issue with people working on IMAP is that people these days have very little data structure and algorithm training, particularly when it comes to implementations of parsers, and so when they stare into IMAP they miss the forest for the trees and barely scratch the surface of what it can accomplish before giving up and screaming for their JSON and HTTP. (That, and the dense numbering for message views, which is a truly-hard thing to get right, even with a lot of academic background.)
Everything you ever wanted to know about Exchange [1] (but were afraid to ask). I personally use SOGo [2] as a Exchange ActiveSync provider but I know OpenChange is a project to implement the entire Exchange stack. So I would not consider it proprietary.
Bundling the sync engine with the client works if you're willing to download your entire mail archive onto every device that connects to your mail. An implementation of the sync engine that allowed only syncing partial mailboxes would be very difficult to implement on top of (all of) IMAP, Exchange, and Gmail. By abstracting that away into a new cloud service, clients end up being both simpler and more flexible.
They're merely implementing their own means to access email in convenient and modern way. Say, IMAP has no labels[1] or contacts[2] (and many other things) - there are proprietary extensions, MS Exchange being the most famous one, but they're... proprietary. And given that proprietary implementations differ, it makes sense to create an unifying wrapper.
And JS apps and web services are just an approach that's trendy today. Personally, I don't like it either, but can't blame for going with the flow. Especially since it's a business (and going against the flow has costs, both in development and adoption), not a private project where one can do things in a way that just feels right, ignoring anything else.
I believe it would absolutely make sense to bundle the "sync engine" within the mail client, though, to make it standalone. But I understand it's done this way just because there was only the engine (as a service, not a library) at the beginning.
____
[1] https://nylas.com/docs/#labels
[2] https://nylas.com/docs/#contacts