It's in the comment that the person was replying to:

"...it will be much easier to run analytics on usage from web access logs..."

Headers don't normally get logged the way that URLs do. Having easy and cheap analytics is very helpful in making the right calls. "Expensive" analytics is really painful with APIs because some people rightfully get scared about the impact of making changes while others will just plow ahead.

Headers are hard to spot in code examples, in traffic sniffers, in logs, and in this case a version can alter the behavior of an API from subtly to drastically producing endless amount of WTFs for your dev team because they can't easily spot what is going on.

We need to strive to make an API obvious and "immutable" (i.e. under one path you get one specific behavior). This in affect means the good old boring /v2/ in the URL path tends to be best if you can't keep everything under one roof by deprecating/removing/introducing single endpoints in the initial version (due to lots of name collisions).

If the different versions have different parameters but share a path you won't be able to document them using openAPI