Debatable.
C++ now have compiler options to let it be translated to pretty much any platform/language in native code.
But yes, on C# its easier, since there are no segmentation fault, in generic case, even if it will be a little bit slower than C++ variant.
Having a library like this in native code introduces a bunch of complications. Namely, the fact that it'll have to be built for every platform. At the very least: one x64 DLL for Windows, ELF for Linux/x64 and Linux/arm64, and Mach-O for macOS/x64 and macOS/arm64. Add in a few more if you want to support 32-bit systems. Cross-compiling is possible, sure, but at some point it'll need to be tested by someone who uses the target platform.
On the other hand, if you create a .NET class library or a Java package, it's one assembly for all platforms. If the code is reasonably well-written, the performance hit will be imperceivable, especially when you consider that C/C++ interop adds extra overhead when used with managed languages (especially if complex types are used). That's the main reason I suggested going that route (that, and the fact that distributing natives can be kind of annoying if you're using a managed language).
Really, though, after some thought I'm not sure how helpful something like this would be considering how many of games seem to use either use Ren'Py or some sort of HTML/JS-based engine (helloooooo Twine!). If they write it in Python as they originally mentioned, at least the folks making Ren'Py games might be able to use it.