Regarding RTC "post-build deliver" described in "How to keep your streams flowing smoothly in Rational Team Concert 3.0.1", that step is about what to do once the workspace has been built.
But, contrary to ClearCase (where a "workspace" or UCM snapshot view would always be associated to an UCM Stream), a Build Definition (with or without "post-build deliver") is always associated to a workspace.
As described in "Creating Build Forge build definitions":
The build definition must refer to a dedicated build workspace, rather than the team stream, so that builds are isolated from ongoing changes in the stream.
When you create said build repository workspace, you will associate a Stream:
In the New Repository Workspace wizard, on the Select a stream page, select Flow with a stream
and in the lower pane, select the repository stream that you want to build from.
This selection enables the repository workspace to accept changes from the stream.
So you always build from a (build) workspace. Even when you don't activate a "Post-Build Deliver" option.
The definition of the build workspace determines the Stream from which you are accepting changes.
Said changes will be accepted (from the Stream to the build workspace) each time you are launching a build.
By "change sets", I mean any change set delivered by any developer on that "flow Stream" mentioned in the definition of the build workspace.