You are correct to be confused with this particular case. It is true, an active/open change set cannot exist in a stream.

There is an explanation for this behavior you are seeing however. Fortunately this is a somewhat rare occurrence.

Quick Summary:
The change set 'state' is cached in your Eclipse client, and the cached 'state' happens to 'think' it's still open when on the server it has actually been completed (upon delivery).

Steps to Reproduce:
-Have a Workitem with an open change set attached to it.
-In Eclipse ClientA (for UserA) open that work item in an editor and navigate to the Links Tab. Confirm you see it as an open change set
-In Eclipse ClientB deliver that change set to the StreamA (Note: The act of delivering will complete/close the change set)
-Now back in Eclipse ClientA, use the "Locate Change Sets" action on that work item and add the stream. The operation will run and it will indicate that the change set is in the stream which is correct. However the label decorator for the change set will still show the active change set. This is because the RTC Eclipse client will cache items it uses across all the views/editors (items being change sets, workspaces, streams, components, builds, work items, etc.). This is to avoid each client hitting the server x number of times always trying to fetch the latest state of each item. Explicit user "refresh" actions tend to force a refresh however.

Steps to Correct This:
You can open up that change set in either the 'Change Explorer' or 'Change Summary' view (in which their 'results' show change sets), and hit the refresh button at the top right of the view. This will refresh the change set, and then label decorators in all the views will correctly show the completed change set icon.