If I were a user concerned with privacy and tracking I might wonder why the authors of the HTTP/2 standard did not make any efforts to address this type of fingerprinting.
This fingerprinting is just sniffing settings negotiated between the client/server, and comparing them to a known list of preset settings for a given browser. I think allowing these settings to vary is a generally good idea, as the best values for these settings aren't really able to be determined ahead of time, without trying a bunch of different configurations out and collecting real world data.
Whenever there is a variation of configuration options between implementations, fingerprinting will be possible. These configuration options are fundamental to how http/2 works. Differing vendors may arrive at differing configurations based on what they believe to be the "best" set of options to use.
If I was an online advertiser, or a company selling to online advertisers, these findings would be mostly irrelevant to me (outside of anti-spam/abuse), as for the 99.99999% use case, the user agent string is probably correct.
It's worth mentioning that there is not enough entropy in these fingerprints to be used as a "super cookie" but rather to just determine whether or not a user-agent string is probably spoofed, by comparing the settings negotiated by the client to settings that the given user agent is known to negotiate. This is a smart approach to determining whether or not a user agent is spoofed, which has its uses in anti-spam/abuse, but a fairly sophisticated adversary could also just have their client send the same settings, and packet sequences as the user agent it is trying to spoof.