Frankly, it don't quite remember the original rationale, but as far a I remember, this is a feature that ended up being only partially implemented.
The idea is that customers may want to enforce all publishing to happen through a (Bundle) workflow. So, you may want to enforce use of a Bundle workflow for publishing purposes. For that reason, you can specify on Schema level that items based on the Schema must go through a Bundle workflow. You can also specify a preferred workflow process (type).
You can define multiple Bundle Types/Schemas and Bundle Schemas can also be associated with a workflow process (type). Together with the preferred workflow process (type) specified on a Schema, we can determine preferred Bundle Types/Schemas. However, there may still be multiple candidates.
Which (publishing) workflow you want to use may depend on which Business Process Type you are using and that is why you can associate Bundle Schemas with a BPT too; this can be used to further restrict the candidate Bundle Schemas/Types, hopefully to the level that there is only one candidate remaining, so the user does not have to choose.
However, in the end things were made less complex (for a "first iteration") and IIRC the UI doesn't help the user in selecting an appropriate Bundle Type/Schema at all. Therefore, both the preferred (Bundle) workflow type and the Bundle Schemas associated with a BPT are not really used at all (OOTB). You could still use these things in an implementation (e.g. event handlers), though. See, for example,
SystemManager.ResolveBundleTypes in TOM.NET API docs.
Another thing to keep in mind is that Business Process Types were originally envisioned to be broader than what they currently are. Currently, they act as Publishing Process Types only (and, retrospectively, that would be a much clearer name given their current scope which will most probably not change anytime soon)