On the other hand, one could also argue that this makes code reuse more difficult. If team A uses language X and develops a nice script using the tool, team B can reuse the script only if they also work in language X.
As pointed out by others, if the functionality is non-trivial in nature, then I'd centralize it in a way that both languages can access (and therefore reuse) it.
My question is: from your experience, what is the global impact of having multiple APIs (potentially more people using the tool, but they can't share their code) or a single one (less people using the tool, but they can share their code)?
In general I've worked on products often that supported multiple languages dating back to even one that provided its own proprietary one (ancient cases before it was so popular to just embed things like Python or Lua).
And practically speaking you do tend to loosen the collaboration between the developers working in these different languages. They're typically going to develop different communities and mindsets and ways of thinking and doing things. The scripting community is going to think and approach things differently and potentially produce different little utility code to share than your Java JNI developer community or your native C++ plugin developer community. And there could be some redundancy of effort there between these separate groups whether it comes in the form of code duplication or something else (ex: even publishing books and documenting how to program your software).
On the positive side you expand your demographic of people contributing to the development and being able to use multiple languages can sometimes even be useful to a single developer. The embedded scripting language might be quicker to whip up something as well as easier to distribute and port (since there are no binaries to build) and safer (ex: no possibility of segfaulting), while the native code might be useful to reach for when performance is a legit concern.
Another team working with Python could reuse this new component with some minor adjustments while the team working with C would have to rewrite the whole component from scratch.
If that component is useful enough to be shared then I'd seek to avoid this restriction. In our case plugins written in script can execute/evaluate plugins written in native code and vice versa (those were always practical requirements in our case since our plugin architecture was about plugins registering components which would evaluate/execute each other, and the point was to make it unimportant what language was used to implement the plugins).
Where I found duplicated efforts was more in the realm of minor things that wouldn't improve productivity that much to seek to stamp out entirely like some minor duplication in documentation efforts, utility functions, sharing code snippets, etc, and just the looser collaboration you get from developers who practically speak and think in different programming languages.
If I can ramble a bit, I also don't always find it productive to zealously maximize code reuse rather than just pragmatically seeking to keep it within practical and maintainable limits. In the worst-case scenario you can see committees emerging and quarreling about how something rather trivial in functionality which barely saves people time to use should be designed in some central library (ex: developers arguing about whether a bounding box class should store centers and half-sizes or two min/max vectors, when they were getting a whole lot more work done just using separate classes in that case in their local projects), with more arguing, toe-stepping, and worst of all, find functionality being moved to central locations which hasn't been thoroughly tested and proven in production enough to be stable enough to direct a lot of dependencies in its direction, only for it to receive repeated central changes that break everything using it.
So these days I don't find it that useful to take code reuse to such a zealous level. I'm not talking about tolerating massive efforts in duplication, or bugs being duplicated, or anything like that, but just to relax it to a pragmatic level (like maybe let's not spend 2 hours in a developer meeting arguing about how to design a reusable bounding box class that satisfies everyone's needs perfectly when such unanimous agreement seems impossible, and not go crazy if a couple of developers develop one specific for their needs locally in their projects), and make reliability and testing of what the developers are producing the ultimate goal even if there's a little bit of redundancy in terms of what they might be doing.