The standards are a single source of truth for your production, if you build solely to a single browsers quirks (in this case Chrome) then those quirks can change at any time.
I still fix FF bugs when they come in (it seems to be a bigger offender than IE recently) but developing for Chrome first is the only approach which makes business sense.
It adds very little extra work with the advantage of surfacing edge cases/issues that might have bitten me even if it was just Chrome in the mix.
Also from a business risk point of view tying the entire platform to a capricious vendor is dangerous and I've been around long enough to remember the days of IE5 then 6.
Once bitten, twice shy.
A web developer codes against real machines, not the imagined, idealized, and non-existent machines the specs describe.
Regardless of browser matrices, it is the will of the developer to support the open web platform that made sure that Internet Explorer and thus Microsoft didn't own the web (browser) in the 2000s.
Anecdotally this point of view has done no harm to me and I'm not the only that shares it.
The reason web developers care about those customers varies from dev to dev. Some believe there is value in a heterogeneous ecosystem of browser implementations. Some have a few high-value customers who refuse to switch (or, in the case of e.g. Microsoft, cannot switch because enterprise constraints are restricting what browser stack they're allowed to run).
But the point stands that when you support multiple browsers, you don't approach ideal user experience (in terms of performance and reliability) for all your customers by throwing your fingers in your ears and proclaiming "That browser is out of spec!" when you find a quirk---you do what you have to do to make your code run on, around, or in spite of the quirk.
Writing to support one browser first was exactly what got everyone down in the deep hole writing code for IE only to find that it didn't work the same in Firefox and Chrome early on.
Also the Dev should be well aware that anything they write to support quirks could well be invalid code such as IE conditional comments.
And then what?
> And then what?
Build to standards first, then accommodate quirks last.
Building to Chrome first is just building to its quirks, and totally forgetting about standards.
"Write HTML, test on Chrome" - what people do in practice - seems to fit "build to standards first, accommodate quirks last" just as well as "build to Chrome first".