I think I’m the biggest proponent of using sensible metrics to determine where work goes (and have been trying to get some things moving in the right direction for quite some time).
I actually fully agree with @stronk on this point - and disagree that this would make the network more centralized.
Broadcasters are the only ones in a position to gauge the quality of a transcode - by whatever metrics they consider important - and it makes sense to continuously monitor for these metrics and switch to orchestrators/transcoders that give the best “bang per buck” so to speak. In some cases, one might prefer the fastest transcode possible (low latency use cases), while in others your might want the most efficiently stored or most high quality transcode possible (long term storage of video assets), or some balance between those (or even optimize for a specific algorithm known to be used by a specific node based on content in the source video).
Broadcasters have to track these metrics, because they want the best transcode and the staking system is not enough to provide guidance on which nodes are the best ones to send work to (it’s not specific enough and only provides a simple ranking based on a single highly ambiguous metric).
It makes sense then, that broadcasters publicize in some way which nodes they consider to perform well and poorly, based on their own interests. For Livepeer-Inc-operated broadcasters, this can simply mean staking towards orchestrators that provide high quality transcodes by metrics their customers find important, but I’d go even further and encourage publishing the data those staking decisions are based on. This also allows those running orchestrators/transcoders to understand what metrics are important and improve their nodes in meaningful ways that add more value to the network by actually providing more valuable services.
I actually want to go even further than just this, since there are some key problems with the media flow going source → broadcaster → orchestrator → transcoder → orchestrator → broadcaster → destination. The most clear problem here is latency: making a total of 6 hops between different nodes, by itself, will add about a second or so of latency even in the most ideal conditions (and usually significantly more). However, that’s actually not the key reason this needs to change: the fact often more than one transcoder operates behind an orchestrator means that their weakest/strongest transcoders determine the performance of the orchestrator as a whole, and that orchestrator is also the single geographic point of entry and exit for a stream. This penalizes transcoder pools, since it discourages having geographically distributed transcoders (even though that is a highly valuable property) and causes poorly picked transcoders for a specific job to negatively affect their ability to provide work that would suit them better.
Ideally, the orchestrator acts more as a representative for transcoders, rather than as an actual man in the middle. It can facilitate the broadcasters in finding good transcoders for the work they have, and act as the trusted payment gateway for the transcoders so they can focus on running an optimal system rather than needing to worry about anything on-chain. Of course, nothing stops anyone from doing both at the same time (or even all three, including running a broadcaster themselves) - but my hope is some of the community will specialize in these separate tasks rather than everyone doing everything. It just makes sense, as one person can’t be good at everything at once and specializing in something is just plain more fun sometimes.
There are way more reasons I would encourage certain changes - I plan to do a proper write-up about this somewhere in the coming month. 
