Reactive / dataflow languages are just perfect for UI binding, and in data-intensive applications (think things like insurance quotes, finance) they can minimize the amount of kludgy UI update logic. The language I wrote was called Gravity (because it kept on sucking in responsibility), and compiled to .NET, which was very easy because it could just use Reflection.Emit and DynamicMethod.
With an in-process debugger I wrote, and the state storage mechanism it used (a bit like a Smalltalk image but with the code referred to via an intranet http URL, so it was really small, less than 60K usually), it had other powerful features, like migrating an app session from one machine to another (think of a helpdesk investigating a problem), playback of the entire application session (for testing or fault reproduction), or post-mortem investigation of the heap.
These kinds of features are very hard to get if you just take what a host language gives you and try and build a DSL on top of it. I understand why many people shy away from it, but the productivity advantages can be substantial, sustainable and strategic. The grammar and semantics of the Gravity language I developed for this were very similar to a subset of C#, except with more SQL-like null handling. That can minimize the learning and unfamiliarity overhead without losing a lot of that advantage. If I were doing a startup today, and it involved the same kinds of challenges, I'd still take a similar approach - and as a compiler engineer in my day job, I don't have illusions as to the depth of the technical problems around production-ready languages and tooling.