You can look at the original writeup – http://magnet-uri.sourceforge.net/magnet-draft-overview.txt – and find a goofy ad-hoc mechanism where local software interested in 'magnet' links listened for localhost web hits, in a certain port range, rather than fighting over the 'magnet' URI scheme handler. That could be seen as either a blathering kludge or a very early attempt at 'web intents'.

I don't know if any code other than my demo ever implemented that localhost-handler trick. But the main idea – of a generically-named URI that was descriptive rather than location-centric – had its own legs. It spread from software to software, even without any formal spec stewardship/revisions. A key step for its longevity, when 'magnet' was adopted to wrap the 'btih' identifiers for DHT-based torrent tracking, happened long after my attention moved elsewhere.

I'd like to think the continuing adoption was because the original draft, even though crude and incomplete, had the right mix of a familiar/defensible URI syntax, wide-open descriptor semantics, and a catchy name/icon.

This is kind of cool, because a file can change locations (how many times have you seen a dead link/File Not Found?), and with a magnet link, if you have a file that matches the description, you can be reasonably certain that you've found the right file (unlike the URIs you're familiar with, which can change the content stored at each location). On the flip side, actually finding the file from the description is a bit more complicated, but as you can see, it's still pretty easy for the user when implemented correctly.

It's better for TPB, because they're no longer telling you 'where' the file is, just what it 'looks' like. Legally, I'm sure that makes some difference.

If the files are different (e.g. 256 and 320 bitrate mp3 files), then that is a completely different problem.