Good news for you: I’m running into this issue. Not exactly how you are, but enough that I’m going to fix it for me, and it should address it for you.
The tl;dr: is that HomeKit views the world as if the dimmer level is independent from if the light is on. Which in some ways is nice. All of my physical (wave) switches remember their last level themselves, and when you turn them on locally will return to that last level. I wish that I was able to “preset” that level without the light’s actually coming on (i.e. after midnight, lights will come on to 20% brightness when activated, rather than the 100% that they were last used at earlier this evening). In HomeKit’s paradigm, this could actually work. But the flip side is any device that can’t remember its prior level must interpret an “on” command as “go to 100%”. This is how OpenHAB is designed - it doesn’t rely on persistence, so it allows DimmerItems to receive ON or a specific percentage, and just passes that on to the binding (or if there is no binding, i.e. a proxy item, interprets it as setting it to 100%). This actually works great for my switches - I can send them ON from OpenHAB, and in the log I’ll see “received command ON; predicted to become ON; changed to 100; changed to 27”. I.e. it forwarded the ON message as-is, then checked the state of the switch and said “hey, it actually went to 27%! woohoo!” (the “changed to 100” never actually happened. That was just the OpenHAB assuming an ON will set it to 100% and updating the internal state of the item before the binding could update the state to match reality). Unfortunately, this totally conflicts with HomeKit’s view. HomeKit thinks I need to turn the switch ON and to a specific percent. For most of my switches, this isn’t a problem - when they receive an ON and they’re already ON, they just ignore it. Then they receive the specific % to go to, and start dimming in that direction. No strobing.
It sounds like your switches interpret an ON as “go to 100%”, so when sliding the dimmer around in HomeKit, they strobe switching between 100% and the actual target very quickly. Normally I’d say “well, get smarter switches that can remember their state.” That’s probably not practical. Next I would say "well, OpenHAB supports persistence, it’d be awesome if there was an option to interpret “ON” as “return to last state” automatically, within the framework. That would get your switches to behave like mine.
BUT… even if OpenHAB core were to do that, that would still leave a problem that annoys me: when the switch is off, and I turn it on in HomeKit, it always goes to 100% (ON and 100% are both sent). No way to solve that except for within the HomeKit add-on itself. So… while I’m solving that, I’ll solve your problem for you generically too, because they’re the same fundamentally. My intention is that if in a single request, an ON and a percent target are received, check the current state of the item. If it’s OFF, drop the percent target, and only pass through the ON command – allowing my switches to do their thing and return to their prior state. If it’s already ON (anything non-zero), drop the ON, and only pass through the percent – allowing your switches to not strobe (and actually improving the amount of traffic on my zwave network, because the superfluous message will now be dropped in OpenHAB, instead of by my end device).
I can’t promise when I’ll have this done, but hopefully within the next week or two. I actually have a proxy item controlling a non-zwave device experiencing some amount of strobing like you have, so I want it for that scenario too (funny story, the item is actually a zwave item, but it’s not directly connected to a load; instead it just uses rules to pass on whatever HomeKit or physical acting on the switch does to another service that actually controls the load). I just have lots of items on my openhab todo list (and real life todo list!), that I may have to do first.