My guesses:

a) Many other tools exist for that.

b) Bittorrent DHT modes are simple and interchangeable. They can give you a list of peer addresses associated with certain (torrent) hash — and only if you know the exact hash. Even client versions can't generally be collected (apart from some protocol extensions). The only thing you learn about DHT member is that it exists. On the contrary, this project is for heterogeneous networks in which peers announce various services.

c) Number of Bittorrent DHT nodes is… bigger.

d) To collect interesting data from Bittorrent DHT, one needs to observe as much third party torrent hash requests as possible. To do that, multiple nodes are needed. Moreover, they need to run for a long time, not just because it takes time to make a lot of requests to a lot of nodes, but also because of external preference for long-running nodes. Not sure how important it is, but, anecdotally, a fresh DHT node sees twice as much requests after a week than after a day.

Because this seems to cater to the cryptocurrency/blockchain culture.

Looks like Nebula uses go-libp2p and all of the supported networks listed in the README use libp2p for their p2p networking. Mainline DHT doesn't support the same transport protocols that libp2p supports (such ash TCP+Yamux+Noise) which is probably why Nebula doesn't support Bittorrent

Because it isn't really network-agnostic.

It only supports IPFS and derivitaves thereof.