This is is a really good idea. The use case I'm thinking of is where the individual plugins need to pull in outside dependencies.
I've had many problems with putting libraries into plugins, which are then also included in other plugins, causing a breakage (e.g. a class is already defined). For example, having multiple versions of the PHPCAS library included by different auth plugins, or wanting to use Symfony components, which some parts of core already include, but at different versions.
Composer should be able to sort all of this out by making sure that a version of the library which works for all of the plugins which require it (and core) is added to the class autoloading path via /vendor.
This would also be a better way to include libraries in core rather than bundling the actual code (assuming the libraries are available via composer).
I would imagine that running composer during each upgrade run, after telling it where the plugin composer.json files are located should be enough to make this work. I'm going to experiment with it over the next few weeks by running composer during
It would be trivial to have the Plugins directory include information on how to add a plugin via composer instead of downloading the code, if that was a route we wanted to support. The composer.json file can include links to a github repo, rather than packagist.org, so no extra work for plugin devs, really. https://getcomposer.org/doc/05-repositories.md#loading-a-package-from-a-vcs-repository