It's also nice if you're running a "vite stack", you don't have to pull in babel and a bunch of other libs just to make Jest work.
Anyway as just the one developer on this project, I don't see the value in writing unit tests for every one of my components. They just work, I'll leave them alone for a few years until someone else builds a new UI.
It's not just the fact that jsdom doesn't fully support all browser APIs, but components are building blocks for a primarily visual medium, so being able to build and debug my component tests visually has been a complete game changer when it comes to productivity.
I think the very reasonable counterpoint to that is browser tests are slow to run, to the point that it's infeasible to run locally at scale. That's why for https://reflame.app, I've been building a testing strategy around using serverless compute to run browser component tests with maximum parallelization for a tight feedback loop that takes ~5s for a cold start and 1~2s thereafter, with dependency analysis to rerun only tests that could have changed to keep cost scaling under control.
I've recently started experimenting with Vitest on a new webapp using Vite/React. It's API compatible with Jest, but integrates with your existing build tool-chain instead of forcing you to configure a parallel one. So far, there's a lot to like. https://vitest.dev/
The `--ui` flag showing a visualization of the dependency graph of a test is probably my favorite little feature.