I think it's likely part of the issues mentioned within the jupyterlab issue 4871. Specifically, the mention in one of the responses.
By default rpy2 will look for the first R found in the PATH. What can happen is that the R in the PATH does not match the R shared library picked up when dynamically loading it.
JMP loads Python as a shared library, so any shared library loading path would need to be in locations that JMP expects. The embedded Python in JMP loads the rpy2 module, an it's shared libraries would be in the corresponding site-packages/ directory. Then rpy2 tries to load the R shared libraries into the process space. If a library can't be found, or fails to load due to a conflict, you will get a process termination deep down in a place JMP can't catch. This was the issue we had long ago trying to use a Conda install of Python on Windows. Conda moved the default locations around and didn't set the rpath, so JMP couldn't find Dlls that Python itself depended on and would promptly exit on trying to run anything Python with an Anaconda based install. Further, none of the loaded Dlls will release and be unloaded until JMP itself shuts down.
I don't recommend using rpy2. My personal preference / suggestion is to use pyRserve. The package pyRserve is a Python thin client that talks to a Rserve server over TCP/IP. There is an example in $SAMPLE_SCRIPTS/Python/Rserve.py that has extensive comments on configuration and use.
This isolates processes much better, and you are not loading R into Python's address space which is then within JMP. With Rserv, a crash or issue within R will then have no effect on JMP. Additionally, your Rserv instance can be run anywhere. Locally in Windows or on macOS, within WSL (Windows Subsystem for Linux) on Windows, on a remote machine (Linux, macOS, ... ). A remote R server may require additional network administration support such as firewall's and allowing ports. Running locally, that shouldn't be an issue.
This is one of the dangers of allowing DLLs to be loaded in JMP. Whether it is from within Python modules or from our own JSL load Dll capabilities. A crash or error in the loaded DLL can cause an unrecoverable and unhandled error in JMP.