I don’t disagree with your technical assessment per se but I would would not label any of this “pretty simple”, except for special purpose apps with technically competent users.
Academically it’s in a decent state, but tech- and UX wise I’d say it’s immature. It virtually penetrates all layers of a normal stack (including layer 8). For apps it’s at least possible but the web is very tricky as a platform for anything e2ee without absurd usage requirements.
The tech choices that remain after deciding on an e2ee model are severely limited and language dependent, and spans deeply across persistence layers, software updates, authn, authz, social graphs, moderation etc etc. And even so, there are many subtleties in terms of privacy and information leakage that are often necessary compromises for features that many apps take for granted today. Without any social aspects it’s significantly easier (eg PAKE is best suited for for interactive/online two-party operations).
I do agree that the UX of a lot of E2EE software is pretty bad, and if you wanted to make e.g. a chat application, then yeah, it's not necessarily "simple". In practice it can become quite a mess. And honestly, I think a lot of apps have just done a poorer job than what would've been possible without much hassle because it's relatively new territory for a lot of developers.
On the other hand though, we're talking in the context of local-first apps, and the set of constraints imposed by local-first apps already does limit you substantially. If anything, local-first is more complicated in a lot of regards; in my mind, the worst part about E2EE is trying to keep track of all of the different keys you wind up needing to wrangle, whereas with local-first, usually, you're all-but guaranteed to run into CRDTs first-thing, which impose a whole bunch of limitations on the structure of data and the operations you can perform on that data. It is possible to share things in a local-first app, but there are limitations to how much a CRDT-based app can scale for a single document.
And that's why arguably, it's one of the perfect places to add encryption. If you're already talking about apps that deal with small-scale documents and that necessarily do most of the work on the client, you may as well encrypt it. All of the clients are "equal" as far as the data structure goes and the server(s) mainly exist to sync to; it's perfect.
When thinking about the E2EE UX of local-first apps, I think of password managers and not chat applications. I think it's closer to the former than the latter in terms of constraints.
Academically it’s in a decent state, but tech- and UX wise I’d say it’s immature. It virtually penetrates all layers of a normal stack (including layer 8). For apps it’s at least possible but the web is very tricky as a platform for anything e2ee without absurd usage requirements.
The tech choices that remain after deciding on an e2ee model are severely limited and language dependent, and spans deeply across persistence layers, software updates, authn, authz, social graphs, moderation etc etc. And even so, there are many subtleties in terms of privacy and information leakage that are often necessary compromises for features that many apps take for granted today. Without any social aspects it’s significantly easier (eg PAKE is best suited for for interactive/online two-party operations).