The primary reason for this feature is to be able to allow users to specify where files are migrated to. The past focus of lfs_migrate seems to be to drain an OST and write objects to any and all other available targets. However, other use cases for lfs_migrate include rebalancing capacity, and moving data between tiers of storage with different performance characteristics.
When new targets are added to a file system, it is beneficial to keep the allocation policy set such that active work will write new files that use ALL targets and retain performance; then old data can be identified with Robinhood or lfs find, and moved to the new targets with lfs_migrate. Adding pool awareness (with a "-p" command line option) would greatly facilitate this work, as all that would need to be done by the admin is to create a pool with the new targets in it.
Note: additional (future) work to build on this and accomplish automatic capacity balancing would be to add another tool or two which:
1) helps manage or automatically create one or more pools of "underused" targets
2) finds old large files and runs lfs_migrate with an intelligently selected stripe count and pool name