So I had an idea, and this might have been discussed before but want to throw it out there.
Basically the problem behind the concept is that we want to activate certain plugins depending on the task. Whether you are opening through be or ftrack, there should be some reference to the task name or type.
We can make a selector that queries this data, and makes a “task” family instance, so the plugins can operate on this.
It’s a very important concept, and very relevant. The reason there isn’t any obvious support for this in Pyblish, is because it is expected to be handled via some other mechanism, something out of scope for Pyblish itself, which is related to environment management.
The basic idea is to handle your registrations dynamically.
Right now, you might have exposed a directory for Pyblish to look at by hard-coding it, either when launching the application or by setting it in the local workstation’s physical environment variables for your operating system.
This works, and is great for getting started and getting familiar with Pyblish, but down the line you’ll end up with requirements such as these, and that’s expected. I’d be worried if you didn’t. 
So it’s good you bring it up, so we can shine some light on it. Talking about potential solutions certainly isn’t outside the scope of Pyblish.
The quickest and most obvious way I would suggest you try first, is to set-up a script that triggers on scene-open.
You’ll want to register your callback as late as possible. That is, when you can get as much information as possible out of the environment about an artist’s intentions. Typically this would be on scene-open, but could also be when launching the application, or by manually switching task from within a host.
It is in this callback that you either set the PYBLISHPLUGINPATH or call pyblish.api.register_plugin_path.
The first thing you’ll notice about this technique is that you’ll have to layout your script according to their corresponding task.
At the moment, you may have all of your studios plug-ins in one giant folder. Instead, think of which plug-ins make sense in which tasks, and lay them out accordingly. If you have to register multiple directories for any given task, that is absolutely fine. Prefer keeping your directories as granular as possible, and register as many of them as you can where needed.
For example, you may need some from modeling in rigging. So instead of making a modeling and rigging folder, think about what is common amongst the plug-ins you need shared amongst the two. You may end up with something like cosmetics, user-data and measurements instead.
The most clean solution to this that I’ve experienced personally, was a combination of setting up the environment prior to launching a host, and having the ability to alter it from within.
The modification took the form of a dedicated button visualising in which environment you were, such as Shot 1, Spiderman, Animation, along with letting you change any of these on the fly.
As you changed them, any tool you used from that point on, respected the currently set variables.
In this case, it would mean giving Pyblish access to different plug-ins, depending on what you were doing.
This approach is just from my personal experience, and I have no doubt that there is a better, even more capable technique out there. We’ll just have to find it, and when we do, tell everyone about it.
One more thing about file management, sym- and hard-links.
Sometimes, you simply can’t arrange your folders granularly enough, but you don’t want to have to copy plug-ins into multiple directories.
Pyblish fully supports file links on all platforms, which, if you aren’t familiar with the concept, works just like file referencing in Maya and other hosts, where the content in your scene isn’t actually the content on disk, but merely references it.
You’ll have to re-adjust your thinking slightly and not think of files as the thing containing the data, but as a link to a physical location on disk. A physical location can have multiple files pointing to the same address, these kind of links are known as “hardlinks”. They differ from “symlinks” in that they are completely transparent in terms of access and general file management in any operating system, including across network drives, whereas symlinks point instead to other files, much like the standard Windows shortcut.
With symlinks, if you move or delete the original file, your symlink will stop working. And to make matters worse, if you edit a symlink, and save over it, you might break the link and instead write a new file with new content.
With hardlinks, neither of these are a risk.
Both have their place though, a hardlink can never be made across file-systems or drives for example, and symlinks are sometimes so transparent that they can “trick” the available-disk-space reader to actually show you the combination of multiple hardlinks, as opposed to just the physical size on disk.
In the case of Pyblish, you could make a master directory for each task, and hardlink the plug-ins you would like to be part of this task, and don’t bother with duplicated. You’ll work out of a separate, “development hierarchy”, and deploy plug-ins as hard/symlinks.