From different sources I understand that, using $ANY have impact in terms of maintenance and testing costs for the customer, because the engine is not able to do as much type-checking in situations where $ANY is used, therefore the customer loses some validation (save-time validation). When the engine sees a class of "$ANY" it doesn't attempt to validate that reference because it doesn't know the class of the rule, so it cannot validate whether or not it exists.
We recently upgraded an application from 6.2.1 to 7.1.9 and post upgrade...
We have no active development as such OR enhancements going forward.
At runtime most activities (that have $ANY / $CLASS / $NONE) did not throw errors in QA / UAT.
Most errors occured at design time only; while editing / resaving / revalidating these activities in DEV.
We did not touch the affected activities as far as they did not throw runtime errors. When we were forced to edit these activities (for whatever reason) we did the bare minimum changes that will let us ‘save’ them without any design time errors.
Bottom-line; take a reactive approach. If an activity breaks at runtime fix it else don’t bother to change anything; leave them as such in PRPC 7.X