ok, a bit of background, based on my understanding (of firmware etc )
this was designed for UI changes made by the user, not automated changes... so low volume messages. (modulation sources were designed for automated changes) - so 'abusing' may have unintended consequences
the call to parameter change in the audio thread, can potentially call a pfunction, so its not just setting a value. I think these are usually fairly 'light' though.
the main issue, there is a separate thread which pushes a usb message for every parameter than has changed (note, it will coalesce on a parameter) - IO is not cheap, so large amount of messages within one 'push' is not good (sent every 2ms) , these messages are not very 'optimal' for a large volumes of data (due to surrounding protocol data) , a large number of changes I think will make the UI sluggish. (probably your issue @toneburst) .... I think its possible lots of messages may cause issues with the watch dog - but id need to confirm this.
as I say this is not bad design/implementation, its just is designed for user interaction, and they only have one mouse
also... I believe Johannes is working on an improvements to the parameter handling, this I'm not sure if PExParameterChange will still exist in its current form, or considered as part of the 'public api' (though no doubt something similar will be required) - im not saying don't use, just be 'aware'.