I don't think you understood the issue. Maybe read it again, or check the change in BitTorrent v2 which provides something similar as per-file trees https://blog.libtorrent.org/2020/09/bittorrent-v2/ (v2 support in clients in the wild is still very low though)
That was a bit tounge-in-cheek, cheers for complementing. Just to clarify, I think its fair to consider v2 if comparing with IPFS (which doesn't really have a large number of mature implementations either).
> BitTorrent v2 not only uses a hash tree, but it forms a hash tree for every file in the torrent. This has a few advantages:
> Identical files will always have the same hash and can more easily be moved from one torrent to another (when creating torrents) without having to re-hash anything. Files that are identical can also more easily be identified across different swarms, since their root hash only depends on the content of the file.
So I guess the question stands, how is IPFS supposedly the preferred protocol over Bittorrent (v2)?
Technically you can do the same thing for the transfer itself in v2. The preference may be for ergonomics where BT requires something like "download this file, from package with this hash, ask these hosts about it", while ipfs is more "yo all, who's got this hash".
You could make the experience similar though if you really wanted. So in theory, no difference. In practice, ipfs solved this years ago, has a nicer interface to it and put updateable naming on top for convenience.
