I can see why linking asset builds to a shot might be helpful. Let's walk through how I imagine that to work out, and let me know if I'm misunderstanding something.
You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it. You then link the assetbuild "characterA" to shot "sh0010".
An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assets on the assetbuild "characterA", because it is linked to the shot, and the animator would need to choose which asset (assetversion) to import.
In a more advanced pipeline you would be able to "build" the shot by importing all the assets needed. We work from the "animation" task launched, finding the assetbuild "characterA", and then we need to assume what assets we want to import.
This workflow could definitely work, but it would be very prone to production mistakes. What asset should the animator import if there are different versions of the rig? This kind of information is usually something a supervisor or coordinator would know. The animator would probably ask, but that doesn't really get us to a very optimized workflow, because we could just skip the linking and the animator would just import the rig asset directly from the "characterA" assetbuild by asking.
Another problem with this workflow is when it comes to exporting Nuke scripts from NukeStudio. Here we end up with a lot of assets (one per shot usually) which the compositor needs to filter through to get the Nuke script asset for their shot.
The ideal workflow is that the supervisor or coordinator can link/setup a shot, and the users get all the assets needed for the shot.
If we go down the case from above, but with the feature of being able to link assetversions to shots, here is how I imagine it going.
You have an assetbuild called "characterA" where you have a "rigging" task. From the "rigging" task you publish a Maya scene with a rig in it to an asset called "rig" with a version of 1, hence referred to as "rig_v1", with a "main" component. We now link "rig_v1" to shot "sh0010".
An animator opens an "animation" task on shot "sh0010". Now the asset importer would list all the assetversions linked to the shot. In this case we only have the assetversion "rig_v1". The animator imports "rig_v1" without the need to ask anyone in the production about which assets should be used in the shot.
This scales up nicely because the decision about which assets to use in the scene has already been made for the animator, so you could essentially have a "Import all linked assetversions" button.
Linking assetversions to shots/tasks also works well when exporting Nuke scripts from NukeStudio because the compositor does not need to filter through all the other export assets but only gets the list of linked assetversions in importer, or the pipeline can easily make that assumption when hitting a "Setup script" button.
There are some areas where this workflow falls a bit short; components and updating.
If a studio utilizes different components than for example "main", it'll be difficult to assume what to import if there is a "Import All Linked Assetversions". This can however be overcome by just bringing all components or the studio making its own "Import All Linked Assetversions".
When publishing a new assetversion, the already linked shots/tasks would have the old assetversions still linked. You would easily traverse the dependency graph and update the links, or leave it and let the asset management part of ftrack-connect handle updating. You would only really need to import all the linked assetversions once, but in the "Import All Linked Assetversions" there could also be a follow up "Scan for newer versions".
Phew! That was quite a post I hope it makes sense, or at least some of it.