From the issue:

because you can typically get similar identification of the service from service.name

Citation needed. I think getting similar information from a resource attribute is fine, but is service.name really the right one? Maybe it should be host.name?
There should be a recommendation which (resource) attributes to set & form the URL from in case server.name is missing.

server.port will be even harder to get from resource attributes, the current conditional requirement seems fine?

Given the recent discussion, I think it is also fine to add an additional condition like "if available from a trusted source" (since the Host header cannot be trusted and a local configuration is sometimes not available)

Citation needed. I think getting similar information from a resource attribute is fine, but is service.name really the right one? Maybe it should be host.name?

it doesn't feel like HTTP concern (a set of resource attributes that describe host precisely). It's the same for all RPC calls and resource attribute definitions would be a good source of information. In practice, it can be a chain of fallbacks where host.name has the highest priority, service.name has the lowest one.

There could be more attributes added to resources in the future that can be even more precise, and HTTP spec should not need to be updated when it happens.

@open-telemetry/specs-semconv-approvers this could use additional reviews, as we are trying to freeze HTTP semantic conventions soon, thx!