i.e. the display list for the page has some boxes for iframes, and those boxes are identical to the rasterizer regardless of what origin they're from, so it happily applies filters to all of the iframes.
As for your second point, how is this not a vulnerability in the browser? The security intent is clear, a page should not be able to inspect an iframe. I can’t take a screenshot and read the pixels of the iframe. The fact the chromium supports a published standard is irrelevant. The browser exposes information it is not supposed to and is vulnerable to attack.
The intent of the css feature was not to allow reading iframe pixels. If that cannot be avoided, then the feature is insecure and any browser implementing it has a vulnerability. If it can be avoided then chrome has an insecure implementation.
I think it would be fair to call it an oversight that Chromium allows cross-origin use of the features involved in this attack, but it doesn't really feel like a vulnerability in the traditional sense to me - everything is working as intended/specified AFAIK. It just happens to expose a timing attack. The reality is that tons of things are potential timing attacks and if every single feature that might get used for one was disabled in advance the web platform would be pretty useless.
There are various constraints you could apply to make attacks like this harder - i.e. limiting filter stacks to say 4 items, limiting use of filters cross-origin - but I find it understandable that such things didn't happen. This functionality is probably also quite old so it's possible nobody was taking timing attacks quite as seriously back then.
I feel like the web platform would be much more useful if I didn't have to constantly worry about drive-by attacks leveraging bugs in a giant stack of "web technologies" that are only getting more complex with each passing year.
Browsers have been making use of GPUs for a long time. It's faster than the CPU and saves battery