For performance, no. But for simplifying the software stack and making it easier to express common control flow abstractions in a consistent, unified, and compatible manner it's hugely important. Not that this API would solve everything, or even much at all, as a practical matter, but it's a very neglected aspect of modern OS and language design.

I can write C code that calls Perl code that calls Java code that calls Python code quite readily, except if I want to use any of their concurrency abstractions like coroutines, async/await, futures, etc. But all of those abstractions merely box function invocation state--otherwise known as a call stack--for a single logically synchronous flow of execution. And we know that all those languages can easily share call stacks.

The issue is that operating systems don't provide a consistent contract for creating and transferring control to different call stacks. They provide OS threads but those are scheduled by the kernel and their implementation and behavior are unnecessarily intermingled with tangential aspects of the runtime environment. It would be like if every time you wanted to call a function you had to use some special kernel facility; not the kind of thing that promotes easy and performant interoperability among different languages or even different libraries.