The compositing API is overly tailored to existing browser engine details. It's forcing complexity onto Web developers when the problem should be solved at the engine level. Having to do all the compositing logic in a worker is terribly inconvenient anyway. If main thread animations are untenable due to random main thread jank, let's fix that instead of adding difficult-to-use workarounds. We're not doing the Web any favors when competing against native by saying "you can get native performance, but only if you contort your program".
An "MVP" that is poorly designed is not an "MVP". There are designs that are flawed due to not having enough features; this is a reasonable candidate for an MVP. But there are also designs that are flawed due to fundamental design problems. Releasing these kinds of designs onto the Web is not releasing an MVP; it's making another mistake.
The CSS Compositing API is basically creating a separate tiny DOM that runs on its own thread because the main thread is supposedly too slow. (It has event handling and everything!) This is counterproductive in my view: it's just poorly reinventing the DOM we already have. If you want to multithread the rendering engine, multithread the rendering engine. Let's not introduce a new tiny multithreaded part off to the side that badly replicates 1% of the functionality of the DOM; that's not a nice way to treat Web authors.
I suspect that most of the advantage of this API in practice would be that it's a thread for the main content to play in that ads can't get to. Until the ads start using it, and then we're back to square one. If the main thread is getting hogged by ads or whatever, let's fix that problem (perhaps via off main thread iframes and off main thread layout). The Web will always be worse than native unless we fix that, no matter how many hacks we pile on top of it.