You can scan a URL very quickly:

    http://myapi.mysite/v1/user/new
    http://myapi.mysite/v2/tweets/fetch

The version identifier is always in the same place.

HTTP headers come in an unordered list. And a client can send any number of headers to the API. And the version identifier may be at the beginning of the list, in the middle, the end, any position really.

Even so, I doubt the resource usage is very different per-request. But writ large it may make a difference.

GNU Grep can search for a string in 41000 files in 1.2s (that's with open(), mmap(), close(), etc). I really doubt that web frameworks are so optimized that matching a particular header would take any perceivable time.

I wouldn't worry too much about the cost of parsing. I'd be a lot more concerned about APIs that rely on proxy and UA caches for performance and/or scaling.

A request has a much better chance of getting cached reliably if all the important semantics are in the path than if they're in arbitrarily-ordered querystring args or headers. Squid's default config didn't cache anything with a querystring up through v3. OldIE wouldn't cache an uncompressed response with any Vary headers. I suspect there are landmines like this buried all over the place.

Uneducated guess: The URL is always looked at, and further up the stack too, whereas headers might not be passed down to the client explicitly?

Would it be a problem in HTTPS, since you cannot inspect HTTPS headers in the proxy?

In the context of a load balancing proxy, you apply the SSL cert to the proxy, and do the encryption there - known as SSL termination. Otherwise like you said, the proxy can't see inside the request (not even the URL).

You can't inspect the path either, only the domain, and even that's only if the browser is using SNI.