The protocol has nothing to do, it’s the way the device reports the scrolling.
The device reports the first notch you scroll almost instantly, but then it waits around 500 ms, half a second, before reporting more notches scrolled to avoid flooding the network, allow time for the smooth transitions to finish, etc.
Unless you scroll just one notch for a very slight adjustment, you have a response time of at least half a second, plus the transition time of the light if you want it smooth. That’s why the scroll is perceived as laggy.
The lag that can be improved but it’s not possible in Home Assistant yet is the on/off toggling by pressing the button. Home Assistant does not expose the initial_press or short_release events to blueprints so they cannot use it to toggle the light fast (when using multi_press_1 it waits for a potential double press).
Edit: Lag vs Scrolling speed
It’s worth remarking this comment was about the lag: you scroll and you don’t see the changes until 500+ milliseconds later. That’s unavoidable unless IKEA reduces the timings.
How fast you can scroll the wheel is another story. Right now the hidden sensors tell you each 500 ms that you’re still scrolling, but you don’t know how many notches have been scrolled to change the brightness proportionally. That’s why in current blueprints, for the same amount scrolled, if you go slow it changes the brightness more than if you go fast. The multipress_ongoing events will fix that when they are available in HA. They are also separated 500 ms though: you’ll be able to get the expected result regardless of the scrolling speed but the lag will not improve.