I'm not sure why this would need to be its own well-known url instead of just a WebFinger resource, considering it's nearly identical to WebFinger already. Would just have to always return a link to an image instead the image itself (or a base64 blob of image data in a property, I guess) regardless of image/* being in the Accept header.
My thinking was that it is one less HTTP request. Rather than call the WebFinger, process it, then call the avatar - this is a one-and-done request for the image itself.
That's true. It doesn't really simplify the server implementation, because you still need to basically re-implement WebFinger to handle clients that don't accept image/*, but it makes it possible to implement a really simple client that just makes a simple GET for an image resource and either gets it or doesn't, without needing to implement any client logic for WebFinger.
I don't think there's really any performance benefit to "one less HTTP request" since you still only even get that case if the client accepts a direct image AND the image is served directly in response to the well known query (instead of serving a redirect to a file store or something where the image really lives), but it might be nice if WebFinger had a method of providing "shortcuts" to resources so this was possible without implementing a new WebFinger-like protocol on a new well-known url.
