We reviewed the mentioned use case above. We reviewed the results of very detailed Patch scalability tests that we performed on the previous releases - unfortunately, they concentrate on the number of SWU (Software Update) policies created, etc. but don't take the number of plug-in policies created into account.
In our usual testing, we normally create no more than 3-4 plug-in policies.
Preliminary tests showed that 200+ cloned "Software Update Plug-in" policies should not be a big penalty. The main attention for Customer in this purpose is to create a correct resource target for each "Software Update Plug-in" policy, otherwise, if the client computer will be in resource target of 1st "Software Update Plug-in" policy and also in resource target of cloned another "Software Update Plug-in" policy, then client can receive not correct policy (only one "Software Update Plug-in" policy can be on client side, multiple "Software Update Plug-in" policies will not arrive to client), which will produce not expected results for Customer.
At this point we can't Support the mentioned use case presented by the customer since we haven't conducted scalability tests on this area in specific. We will add this to our future releases as part of a separate testing/research QA task. Normally our guidance to the customers was to control different behavior using separate SWU policies created for different sets of computers (but this would be limited to controlling the installation time, not restart time).
A feature request has been opened to add this scalability test to our QA process. No ETA (most likely next major release post-ITMS 8.6 RU3 release).