First find which part is slow.

emjupy-language-support set to nil disables every path that contacts a language server; notebooks, kernels, output and rendering are unaffected. If the delay goes, it came from language support.

emjupy-report-slow-hooks, set to a number of seconds, reports any per-command work exceeding that duration, naming the function responsible.

If neither points anywhere, measure rather than guess:

M-x profiler-start RET cpu RET
  ... move the point around until it feels slow ...
M-x profiler-report

The top entries name the culprit. If they are emjupy functions that is a bug worth reporting with the report attached. emjupy's own per-command work is small – a cursor move costs well under a millisecond – so on a notebook full of figures the usual answer is redisplay_internal or image scaling: the notebook is asking Emacs to draw more than it comfortably can, and clearing some output (emjupy-clear-all-outputs) confirms it in seconds.

The language server answering is on this machine, not beside the kernel, so it cannot see the files the kernel can. M-x emjupy-lsp-diagnose will say "a local process", and M-x emjupy-version "language server on this machine". Install jupyter-lsp and a language server where jupyter server runs – see Requirements – and restart the server.

If the cell is not really still working, the kernel most likely died – out of memory, or the code exited – and the server restarted it without telling the notebook. C-c C-x C-c reconnects to the kernel now there and ends the run; anything the old kernel held is gone. Why, in Known limitations.