I think I'm definitely going hard on using the word "improper" but my justification is that you're going to write "client side" code either way. It's going to exist in blade templates, or web components. Where I see the react ecosystem moving is write-once components that can then actually be used cross-platform. I just can't justify to a client (or myself) tossing HTML in blade templates and tolerating postback page load times anymore. I look at it as a sort of separation of concerns on steroids, beyond just domain design -> into the full application desgin. I like (and real-world use has proven) the idea of two very cleanly separated contexts, one where I'm writing only an API, and one where I'm only writing client-related code. I can make sure either side has only the code they need, only the tests they need, and there's no mixing of code. I don't even need a web browser for my API, and for React with jest/enzyme I barely need one for writing clients now as well.
The middle ground I'm warming up to is having the first-load server-side rendered React being served up instantly for the user, which definitely improves their experience. I'm just not sold on it as a "staying around a while" way of doing things.
I'm also not preaching this universally as a solution for all projects or problems, but I think if you're going to be writing forms/posting/jquery datepickering/handling DOM code anyways, why not separate it cleanly instead of mashing templating and back-end code together?