It works fine with those plug-ins I’ve tried, but we’re doing plug-ins not hosts, so I only have a limited set of 3rd party plug-ins installed, and am using only the sample JUCE host.
The issue came up because it really hurts performance with our plug-in, particularly when ARA mode is used, which increases the number of instances dramatically because it’ll be one plug-in per region/clip, not per track, so heavy-duty per instance adds up much more.
Further, in hosts that call reset() from the render thread (e.g. Mixcraft), this causes setActive() to be called concurrently from various threads (albeit for different plug-in instances, but if the instances share any resources there will be lock contention issues, making the issue even worse).
I fully understand your concern about outdated plug-ins that may be bugged, but this is seriously hurting well-behaving plug-ins in otherwise well-behaving hosts. As more and more hosts and plug-ins are adopting ARA, this will become even more of a headache.
If you really want to keep the old behaviour, why not limit it to old plug-ins? For example, you could test whether the plug-in supports ARA, in which case it must be reasonably new and if there really is an issue there will be a near-time fix. There may be other interface that can be tested to reasonably determine whether or not a plug-in is under active development, for example ChannelContext::IInfoListener which Steinberg added in one of the rather recent VST3 SDKs.