I don't have any reason to believe that the Chrome team pushed for this use case specifically. In the past when I experimented with SVG filters their feature support was already very different across Trident Edge, Chrome, and Firefox, as was their implementation (hardware accelerated vs not). SVG filters are very powerful and also very slow, and not necessarily constant-time, so they're a good target if you're trying to execute a timing attack. (For whatever reason, my old JSIL project actually happened to use SVG filters to accelerate a specific use case...)
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.