Clearly those commenters don't have much experience working close to the wire around GPUs then. Scanout used to be very closely tied to rendering, and in some ways it still is. You can't take an arbitrary texture in GPU memory and scan it out to the display.
Windows has this thing called VidPN to work around the dependencies between source and target modes which gets even more complicated with VRR and virtual resolutions (retina).
https://docs.microsoft.com/en-us/windows-hardware/drivers/di...
This has become a lot more important with smartphones than desktop systems. You now have often very different silicon for things like video decoding, graphics and scanout - and to achieve reasonable battery time you need common use cases like watching a video to not involve the GPU at all.
They're exposed as an independent engine on the GPU/SoC and can operate with most of the chip power gated.
OK, so first off, FKMS vs KMS.
KMS is Kernel Mode Setting. This is the kernel's framework for setting video modes, abstracting over HDMI/DSI initialization, timing parameters, etc. etc. across platforms.
FKMS is still KMS, but it's a special KMS driver for the Pi which sets up HDMI using the DispmanX API into the Broadcom proprietary OS that runs alongside Linux on the Raspberry Pi. This is nice because it's dead simple for Linux (Linux quite literally gets to say "yo, gimme a 1920x1080 layer!") but bad because it relies on a proprietary blob and the blob can't be extended.
Native KMS, on the other hand, sets up HDMI using native device access to the actual registers which affect the HDMI encoder, DSI link, and so on. This is more extensible and isn't closed source, but it's also mega complicated.
Now, here's the kicker on your Pi. Other commenters are correct that normally, KMS should just affect mode setting, not rendering. But, on the Pi, this isn't true. KMS and FKMS _also_ affect the way _layers_ are configured in the DRM (Direct Render Manager) subsystem.
Why? DispmanX isn't just a mode setter, it's also a scaling and compositing (layering) engine!
So, in the course of bypassing DispmanX, the DRM system in KMS mode now needs to act differently - it needs to configure 2D compositing planes through the KMS system instead of through DispmanX.
What's on a separate 2D compositing layer?
The legacy cursor.
Here's the switch where RealKMS is responsible for setting up the cursor compositing layers, a task which in FakeKMS was already handled by DispmanX:
https://github.com/raspberrypi/linux/blob/aeaa2460db088fb2c9...
https://github.com/raspberrypi/linux/blob/1fe617a917eac75800...
Now, _why_ this makes your cursor lag, I don't know, but that's the difference.