Of course the approach is not a catch-all. A web browser that cares about performance isn't going to want to spawn a process for every bit of JSON it wants to parse, etc. Spectre has made this even worse, since now isolates/VMs are no longer considered boundaries - now every single site has to be isolated from every other (as is addressed in Chris's talk), or you need some sort of heuristic, or whatever.
There's also a massive gap between basic sandboxing and what Chrome does. Seccomp is very hard to maintain, but broader sandboxing like Windows Integrity or DAC on Linux, Apparmor, etc, are quite simple both to implement and to maintain.
What's notable about the ITW attacks is really just that
a) Chrome really owns the market now, and attackers know it's worth the time to exploit
b) Attackers have likely incorporated enough research and tooling to more cost effectively find vulnerabilities in Chrome
c) As the article points out, a lack of memory safety is extremely costly to try to make up for using just one other approach, even a great approach like sandboxing.
From the OS, which provides the sandboxing primitives, up to the broker, and into the renderer, we have memory unsafe languages. Shocker that sandbox escapes occur.
Sucks that Google is so invested in C++, it's obvious that organizational inertia has kept Rust out of Chrome.