UPDATE: In order to see if the "stranded" memory left by activity B is in fact a problem, I created a loop between activities A and B:
--- A calls startActivityForResult() on B
--- B calls finish()
--- onActivityResult() in A calls B again, etc...
I let it fly for about 15k iterations, and the program did not crash. So even though the JVM on this phone and OS version (Samsung S3, 4.1.1) leaves references to class B in memory, even after activity B calls finish(), it appears there is a later clean up of some kind, as the number of references to the B class did not monotonically increase during the test.
In fact, I generated several heap dumps during the test and never saw more than about 100 instances of the B class -- as opposed to the 15k I would expect to see if there were no other clean up. GC statements in the logcat also showed memory use going both up & down, in spite of the large number of invocations of activity B.
My conclusion is that I should not worry about the existence of class B references in the heap dump after finish() calls, because it appears that the JVM used on this phone/Android version does some kind of deferred clean up.
Note: This is my inference based on the test I ran, so if anyone knows differently please share. Thanks!