For me it's not just the cursor, it's the whole session. All animations become laggy on Wayland under high CPU load, but the cursor choppiness is what you see the most easily.

Can you please check whether KWin is running with real-time scheduling? The whole idea of giving real-time scheduling was to prevent laggy situations on heavy system load. But not all distributions were able to deliver it (in case of openSUSE I remember that the security team had comments).

How does one find out that information?

You can use ksysguard. Enable the process priority column and check whether kwin_wayland is marked as realtime or FIFO. I would like to give you a screenshot how it should look like, but on KDE neon it's defunct and my kwin_wayland does not use rt-priority. (if it shows a 0 it's wrong).

You could also check 
getcap /usr/bin/kwin_wayland

it should print:
/usr/bin/kwin_wayland = cap_sys_nice+ep

make that:

getcap `which kwin_wayland`

AFAIK Nate compiles his own kwin...which also wouldn't have setcap set.

(FWIW my new pending systemd boot should also fix this in a way that won't require root anywhere)

Yes indeed, I compile my own KWin. Is there a way to compile it with this support turned on?

cmake looks for optional build dependency Libcap. Verify that you have built KWin with that dependency. In case your KWin is built with libcap support do:

sudo setcap CAP_SYS_NICE=+ep `which kwin_wayland`

Unfortunatelly you will have to do this after every make/ninja install. In case you run make/ninja install as root, this should be done automatically.

I'm not sure if using setcap on kwin_wayland is correct: Now all desktop processes are running with FIFO/1 priority, probably because plasma forked from kwin_wayland.

On supported kernels, it could try to use isochronous scheduling which is supported by some kernels and doesn't need special privileges: It works mostly like FIFO scheduling.

But in the first place, it shouldn't spawn any processes while running with raised priority.

Also, why doesn't it use rt-kit as a fallback? Or a small suid helper which checks if the parent process is kwin and then changes the priority?

Wayland definitely becomes laggy and slow when the system is under load (I've tested various distros and builds from git). It's not just the cursor however, but with that said gnome seems to have moved the cursor rendering to a seperate CPU thread... Perhaps the same might be good for Plasma Wayland?

BTW: It's not only the mouse cursor lagging, key presses are also simply not detected. And this even happens with a low average CPU load if you just have some processes stuck in IO for a few ms: I was thinking I'm not able to properly spell words any longer with this because every now and then, a letter goes missing while typing.

I haven't really noticed this at all on Plasma 5.21 Beta. I tried running prime95 and noticed no cursor lag at all, even during the CPU torture-test.

This bug doesn't really contain anything particularly actionable. 

We will always get some lag under extreme load. The amount is variable, so this falls into generic optimisation, which is something we're always doing regardless of a report.

I'd say that "loss of input events" should be actionable... (reported in comment #11) I don't care if mouse lags behind a little bit or jumps during CPU spikes, this also happens using X11. But it also loses input events (some keypresses are just discarded), and this particular problem seems very sensitive to even slight load spikes, and it was really distracting as texts I type had a lot of missing letters as if I couldn't type properly.

I'm not sure if this has been fixed meanwhile because I switched back to kwin_x11 for that matter (and a lot of other quirks like context menus showing as windows etc). I'll give it another shot with 5.21: Seems at least a lot of quirks had been fixed.