Yes, you may be right. I dug into the code to figure out which part would be responsible for (re)setting the brightness, and I believe it’s DDCutilDisplay::resumeWorker(), specific to ddcutil support. This is called in response to ddcutil’s DDCA_EVENT_DPMS_AWAKE event. The timer that’s started in resumeWorker() will end up writing the brightness at the currently configured level.
Please try out running PowerDevil with POWERDEVIL_NO_DDCUTIL=1, as described in the README. This may end up being a permanent solution for your use case.
The bigger question is what should be done about this, assuming my reading is correct. We could of course simply take out the brightness setter from resumeWorker(), although I think this isn’t desirable for most use cases. @Zamundaaa argued that KWin/PowerDevil should always be in control of screen brightness, which I have yet to respond to. I think desktop-independent tooling such as midi-pipewire-volume are a good example of why we should strive to co-exist with other brightness setter tools that use ddcutil directly instead of our new org.kde.ScreenBrightness interface.
Either way, we should try to figure out a way forward. Thanks for bringing this to my attention. (That said, this thread should have still been a bug on Bugzilla imho.)