Currently, touched events will fire irrespective of the collision groups of the two parts involved. Now while this is not much of an issue from a game logic perspective - CollisionGroupsAreCollidable exists after all - it can create an extreme efficiency issue under some circumstances.
For example, working on a car game, you may wish to ‘ghost’ other players cars under some conditions, locally changing all the parts in the other car to a different CollisionGroup which does not collide with any other groups, allowing you to drive through the other car.
However, if you also have touch events attached to your car, for say collision sfx or other purposes, these touched events will cause massive physics slow down when your cars intersect, as the engine rapidly tries to process the thousands of collisions that are now happening every frame.
oh - oh no
I have also encountered similar issues in the past - zombies in a lot of Innovation games used touched events to spread infections, which caused significant slow-down when zombies interacted with players holding tools with lots of can-collide off parts or wearing custom haz-mat suits.
While changing the default behaviour could potentially break a lot of games, one potential option I would really like to see is to add a new method to BasePart that accepts a CollisionGroup and returns a touched event filtered to that specific collision group. This would hopefully solve the slow down issue in the above scenarios, and nicely complements the recent changes to ray-casting to accept collision groups.