A big reason is that the two ways are almost the same, so it makes sense to choose one instead of supporting both.

The HTTP approach has two advantages over the DNS approach:
1. it's easier to add other metadata to the pubkeys, like we do today in some cases;
2. it's 10000x easier to support dynamic name resolution, for providers that have multiple users, each with its own name and pubkey.

The first NIP-05 draft used DNS records, but then I realized that it was inferior. 

 People who have domain names are generally capable of hosting websites. It's not a big burden.

If you already have a website, adding a static file or a simple 3-line handler for /.well-known/nostr.json routes is super easy too (unlike with the Lightning Address LNURL scheme which required an active process capable of generating invoices). 

 using nostr webserver+relay  but with regular DNS pointing . so how can nostr naming be an advantage? without using DNS of any sort or via onion 

 What do you mean? It's just a way to point a human-readable name to a pubkey. 

 This seem reasonable, thanks.