The only one I can think of is developing a UI library, but for the usual SPA development, it seems to me that MSW provides a much smoother and less obtrusive dev experience without affecting how my app is architected.
I'm going to use Oxide console [1] as an example because it has a really good setup of MSW + OpenAPI autogenerated mocks (which means that it doesn't need any complete running backend, just a defined contract).
Consider this fairly simple page [2]. If I'm using the Storybook pattern, I'm keeping all of the state outside of the component, which means I now have to manually memoize every single variable defined before the return to make sure that the component doesn't do any unnecessary re-renders. This includes `intervalPicker`, `commonProps`, `setFilterId`, every return of `useDateTimeRangePicker`. With MSW I have benefits of not needing the API as well as developing in the context of a real production app, using the same exact mocks for unit tests and development.
[1]: https://github.com/oxidecomputer/console
[2]: https://github.com/oxidecomputer/console/blob/main/app/pages...
That way you could render this component without any changes to it.
We may have been using it incorrectly in my team, but our pattern is moving out all of the state out of the component, essentially separating the logic from the view.
Also very useful for non technical stakeholders (design, product, etc) to test UIs in isolation.
They're both amazing tools, solving intersecting but different needs.
As part of your SPA (or MPA) development, UI state complexity will inevitably grow, and shipping seemingly small cosmetic or logic changes becomes scary.
Documenting component states in Storybook and plugging it to a tool like Chromatic or Percy or Applitools, will catch visual/accessibility/interaction regressions as a CI step.
I work at Netlify where it's an integral part of "how we build", and the peace of mind we get out of these tests is amazing DX.
In another project we've adopted React Server Components, and no longer have an API - so MSW is not even an option there. Storybook does work, although it's still a bit of a hassle to have to split our Server Components into two components, only one of which actually makes use of server-side APIs.
What I'm saying is that effectively, my team has been using Storybook to develop components in isolation from the backend or the rest of the app and this was the main feature that we utilized. For example, we develop whole pages in Storybook. Our use case is that we also don't have a component library which is what people use it for primarily, from my understanding. Component library is a valid use case for teams who have a homegrown set of components but we don't have one.
So in our use case, developing a component in Storybook meant writing a story that passes all of the props and different prop variations to a component that doesn't have any state inherently. Swapping Storybook to MSW allowed us to avoid structuring components in a specific way (e.g. separating state from the JSX) while retaining the benefits of not having to have a complete backend.
In conclusion, we used both tools primarily to develop our SPA in separation from the backend. MSW filled this niche (which was specific to us) better.