kokolem This is also true for work profiles.
Not in the same way user profiles do. By their very nature, user profiles provide totally different workspaces and GrapheneOS provides the option to put the entire profile at rest with an "End session" button. Encryption keys are protected by their lock method like you would expect. You don't get that flexibility with work profiles.
In fact, each user profile has its own Weaver slot on the secure element. Compared to stock OS, GrapheneOS raises the number of user profiles from 4 to 16. That's one of the ways (including the upcoming cross-profile notifications feature) GrapheneOS aims to make user profiles more convenient and the de facto choice for compartmentalization.
By design, work profiles are also made to allow communication between apps on the user profile and the nested work profile. That can't happen with apps on different user profiles (even the with the mutually consented IPC that takes place in a user profile) unless they use network (which can be revoked by the network permission, including localhost).
(Also to be clear, the app sandbox always applies whether you use work/user profiles or not. These profiles are not substitutes for the app sandbox.)
kokolem This is the only disadvantage of work profiles I see, although it's quite a big one.
Yeah, because the device manager app has ownership over the data of the work profile it manages, and not yourself, fundamentally. You're trusting a third-party app with considerable permissions over that data. Work profiles were designed with BYOD deployments (bring your own device) in mind.
For these reasons, we often recommend user profiles as the preferred way to create isolated workspaces. I hope I was able to give a satisfying enough answer to explain why.
External documentation to learn more about user/work profiles: