It's more complicated than that though. Slow start is tuned for long-lived pipes sending large files, which doesn't match the observed load. And in any case the congestion bottleneck on modern networks is almost always in the last mile to the client anyway: most web services can freely pump as much data into the network as they want[1].
[1] Jim Gettys and his bufferbloat posse might have something to say to you though.
This is something that I think is slowly going to bite us big time. So much memory out there so much ability to "absorb" and retransmit. That gives the network a sort of 'resonant' frequency with respect to packet retransmission. I could imagine doing the Tesla trick of injecting burst of packets into the network at the resonant frequency and being able to get all the buffers to explode.
You'd probably find reading up on systems dynamics to be interesting. Systems with multiple stages linked by delaying steps tend to have quite dramatic oscillations. A great example is "The Beer Game"[1]: small changes in purchases of stock leading to massive whipsawing of production schedules.
Yes, I think those bloated buffers can easily absorb 10-packet bursts. If bufferbloat gets fixed there may be packet loss in the initial window burst and people should adjust window sizes back down. But I wouldn't worry about less-slow start unless it actually causes packet drops.
That's the problem though isn't it. The buffers absorb the packets, preventing packet loss, and TCP performance goes down. Adding more initial packets puts more data in flight, more traffic uses intermediate buffers quicker. This tactic seems like it would accelerate buffer issues.
Like someone said in the comments on the article, I'd like to see Van Jacobson's or someone similar's thoughts.
No, TCP performance goes up for the connection in question. Latencies are lower because the packets arrive earlier. Latency (for all protocols) goes down on the whole though due to the backlog.
Balancing these requirements against each other is a really hard problem. TCP slow start is (well, was, c.f. this article) an early attempt to get an auto-tuning solution. But it isn't the only part of the problem, nor is it an optimial (or even "good") solution to its part of the problem. It's defaults are very badly tuned for modern networks (though they'd be a lot better if everyone was using jumbograms...).
[1] Jim Gettys and his bufferbloat posse might have something to say to you though.