This is functioning as designed.
The goal is designed to update the version of the specified project (i.e. by -DgroupId=... -DartifactId=... -DoldVersion=... or picking up the defaults from the aggregator root, a.k.a. the project in the current working directory or the project referenced by -f) and ripple that change and any consequent changes through the largest effective reactor that can be constructed from the current reactor.
The reactor is expanded by looking in the reactor root's parent directory for a pom.xml that has a <module> that points back to the project... this lets us discover the whole "effective" structure of pom.xml files to evaluate the scope of the change.
Based on the specified change initiator: groupId:artifactId:oldVersion->newVersion it looks to see if that change has knock-on side-effects... so if the project being changed is used as a parent for other project and those child projects do not explicitly specify a xpath:/project/version and instead rely on inheritance from xpath:/project/parent/version then those child projects are added to the list of changes.
Once the list of GAV changes is complete, the plugin then checks all the <dependency> references to see if they match any of the oldVersion's used in the final list of GAV changes, in which case they are changed to the newVersion
What would be a valid enhancement (if I didn't implement it already) would be to allow the use of wildcards in the groupId or artifactId. With such a feature the end-outcome you desire could be achieved by running, e.g. mvn versions:set "-DgroupId=*" "-DartifactId=*" "-DoldVersion=*" -DnewVersion=2.1-SNAPSHOT but a separate ticket should be opened for such an enhancement.