refresh rate switching is essential if you want (micro-)stutter-free, smooth video playback
Sorry, I had confused chewitt answer "refresh rate changing for optimal media playback" with kodi 'optimal' setting for variable refresh rate changing within a media file. Now I get it.
Regarding DV: UHD Blu-Rays have a mandatory HDR10 base layer, so DV on these disc is an additional layer on top and RPi4/5 will output the HDR10 layer just fine - tested that here with 4k (DV) Blu-Ray rips I did on my own with makemkv.
Regarding HDR10 mandatory compatibility layer on DV rip sources, yes it is there but on HDR displays with lower brightness than content's mastered luminance you need DV (or some kind of) tonemapping, otherwise highlights are blown-out, because HDR10 displays don't tonemap higher nits to their range, only DV does. However, my Samsung S95B tv is non DV and 1,000 nits capable and it can 'map' 10,000 HDR10 content correctly. But a Sony DV-enabled tv clips with 1,000 nits HDR10-only content, only DV content is shown correctly. So sending HDR10 compatibility layer is going to clip highlights on many tvs and monitors, since most of these won't reach content brightness.
RPi4/5 certainly wouldn't have the grunt to process that - direct-to-plane rendering works fine for 4kp60 but GL/EGL rendering doesn't - it's too slow, even without shaders having to do tonemapping
I understand a RPI4/5 may not have enough power for vulkan or opengl shader tonemapping, no question. Certainly HDR is not working on linux yet, and LE has the lead here. RPI OS Kodi package appears to use FullKMS open source driver and it has full 4k/HEVC acceleration. Maybe it's the same thing LE uses.
I've read Wayland can live over KMS. Probably it's an additional layer to direct KMS and slow things up as you say.