Have only played with LiveView in a toy project so far, so pinch of salt and all that, but from what I’ve learned it mainly comes down to what level of latency is acceptable.
If you need a UI that responds with low latency, you won’t be able to guarantee that with LiveView unless you run a lot of custom code on the client side – and then what’s the point. If someone’s on a slow mobile connection, or has a slow ping to your servers, that will affect round-trip times for every interaction. Though LV does a lot to keep data payloads small.
That said, for many applications, that kind of latency is fine. If you’re filtering a search or validating a form, you likely won’t notice – and the search filtering would probably require a server roundtrip anyway, so wouldn’t be faster in React.
Optimistic UIs, like switching the state of a “Like” button are easier in React, too, of course, since the client owns those visual states and can switch them immediately and send off a request later. In LiveView, you’d either wait on a round trip, or have to maintain some custom JS (and again – if you do a lot of state management on the client, what’s the point?).
I think of those more as trade-offs than as negatives. I don’t believe LiveView aims to be a React replacement in every situation. If you’re working on something that requires a low latency UI and a lot of optimistic changes, I’m sure Chris and José would be the first to tell you to pick something like React 
Oh, and also – for secondary bits of interactivity like collapsing/expanding content that’s already loaded on the page, you can still use sprinkles of JS for that. Some effort has gone into ensuring LV works well together with Alpine.js, for example.
Edited to add: Offline apps are also a no-go, of course.