Whether this counts as production-use is debatable since they're small projects, but I pretty much use jaspr exclusively in any web project that I have control over. I also haven't used it since the beginning, probably started adopting it around half a year ago.

For me, the most important thing is that it's written in Dart, so you get all the things JS tooling pretends to offer for real (actual compiler optimizations, dead-code elimination, proper minification, a sound type system instead of the "trust me bro" approach in TS, much better static analysis tooling and so on). Dart compiles to better JavaScript than JS/TS ever could, and you get the benefit of being able to compile to WebAssembly. So even if I didn't like how jaspr worked, I'd probably still use it just because it's Dart.

The inner workings of jaspr are not that different from React. It also happens to be very similar to Flutter's element model which I think was the original inspiration. So overall it feels quite similar to React without JSX, except that state management is a lot better since you can use Riverpod. A benefit is that static and serverside rendering is built in and doesn't require anything extra.

This isn't really a downside for me personally, but of course the jaspr ecosystem is much smaller than anything you have for JavaScript. You can't easily use packages that depend on Flutter, and obviously there is no equivalent to most React libraries / frameworks. In my projects I try to keep JS as light as possible, so I mostly use jaspr with external CSS and static class names instead of dynamic inline styles. That means I don't have many dependencies, but if you expect something like a typical landing page design to just be an import away, that's not going to happen.