Not to pick too nittily, but your assertion that a load balancer should just "go[es] to the most responsive server" is kind of simplistic. When I was working there, we had a failure mode where the most responsive server was one that had tripped over a subtle bug causing all subsequent requests to that instance of the service to almost immediately respond with an http 200 and empty content (it was a bug, after all, and it was compounded by this failure mode of returning a 200). Because we used weighted round-robin, we were able to diagnose that only some of the servers were behaving badly and could focus on reproducing the problem, finding the root cause and fixing it. The short-term mitigation was to bounce the ones in a bad state as they got into the bad state. This was at the cost of a poor user experience for 1/n of current traffic. In your proposed model, all traffic would have black-holed into this highly responsive server possibly making diagnosis and mitigation more difficult.
As far as having to abstract away the heavy lifting of service management into a dedicated layer, I'm in violent agreement with that architectural decision. Without providing service management as a service, you put the burden on everyone's shoulders to manage it themselves. I'd rather have 98% of the developers focused on application logic and a specialized 2% of the developers providing productivity improvements to the core platform.
While it might be more rewarding for some to re-blaze trails that have already been explored (and improvements do come out of parallel efforts) it's a much better business decision to put as much weight as possible behind moving the product forward and leave the task of lifting the efficiency of the platform to a dedicated team.