There's a set of problems that tend to go together when you're doing audio tech development: We have to build apps/plugins that run on many platforms and plugin APIs (so managing many different compiler projects for the same codebase is really helpful). We always tend to have complicated and custom GUIs (hence all the GUI framework stuff). And there's a whole set of other commonly needed library code that we provide.
Re: the live-coding stuff, initially we've found it really useful for GUI design - isolating individual GUI classes and nudging their code around to get the behaviour right, rather than having to repeat the tedious edit->compile->run->navigate cycle. But it has a lot more potential uses that we're just starting to explore, and hopefully as it becomes more solid, our users will think of even more things it can do.
Then for anything that is an arbitrary data transformation it could be done live and in isolation.
So it would take a really strong incentive for someone to create and maintain a full-featured binding to another language.
But TBH I've never quite seen the point of binding scripts to C++ classes in general.. C++ is already a great way to write that code, why have a messy layer in the middle!
The place where I'd have thought it makes sense is for custom APIs, e.g. in Tracktion we let the users write javascript to control the app in response to keyboard shortcuts, but for that we have our own API that they can call. Never quite understood the use-case for more general library bindings to generic GUI classes, but I guess people have their reasons!