keystone-manage bootstrap creates a role assignment for the specified user on the specified project. That is one way someone might want to do bootstrapping, but there are good reasons a user may need/prefer:
1) user-domain role assignment... e.g. Switching identity drivers for an existing single-domain multi-project configuration. Bootstrapping is needed to configure the initial role assignments for the new driver. Since the "cloud admin" concept is not essential for single-domain environments, it may very well not be configured, yet the initial role assignment needs to grant someone the ability to create additional role assignments for all projects in the domain. This would be a domain admin.
2) group-project role assignment... e.g. Where the desired end result is for a group-project role assignment on the cloud admin project, it makes more sense to allow that to be created directly (which could be done without even knowing the password of any user in that group) than to require bootstrapping of a single user and then using their account to create the group assignment and delete the bootstrapped assignment.
3) group-domain role assignment... e.g. combination of #1 and #2
Generally speaking you could also do the group setup after the initial user is created. The idea behind bootstrap is meant to really just solve chicken-egg problem without encoding defaults into the db migrations.
With all of that said, it's fine to expand keystone-manage bootstrap to be more flexible. Just keep in mind it shouldn't be "the way" to populate everything in keystone - it should be the basic necessities so that the basic setup can be finished.