Yes, this is still true.  Although for what you are looking to do, I don't think this method would work well for you.  I don't you want to delete an artifact to remove it from scope, because deleting is fairly permanent and it's not easy to bring it back (as suggested in #2).

I think the following method would work better, but let me know what you think.  You could keep the same set of requirements in the 2nd stream, but within the 2nd stream, use attributes to mark whether a requirement is in or out of scope.  If you're using modules or collections, you could have a module or collection that represents all of the in-scope requirements; otherwise you could create a view that just shows you the in-scope requirements. 

Then, as requirements later come in to scope, you just have to change the appropriate attribute, and add them to the appropriate module or collection. 

wrt #3, if CM is enabled, you are always using change sets.  You can manually create change sets and provide them with meaningful names and changes, and deliver them when you want.  If you don't, the system will automatically create change sets for you.  The automatic change sets may or may not be the scope you wanted, and may not be named in a way that makes it easy to find a particular change. 

If you want to be able to pick and choose the change sets to deliver, manually creating change sets is recommended.  If you plan to deliver changes at a macro level (e.g., deliver ALL of the changes made in stream 2 back to stream 1), then the automatic change sets may be enough. 

(Note that there is a setting to enforce manual creation of change sets for all changes if that's the path that works best for you). 

Hope this helps.