The native provider will function faster than ODBC because you have one less layer of translation happening, but consider this situation, which I ran into when we got onto our new web platform, which consists of two dedicated boxes (one web/app, and one data).
The two boxes are sitting in a cabinet on their own little subnet. Connection between the two boxes is 100mb/sec. 1.5 mb/sec on the other side of my firewall which leads to the DNS servers about 10 cabinets down (actually, I lose a little of that speed through the firewall, but... close enough).
In this case, a DSN offers me just as many ups as it does downs. Yes, a registry lookup happens each and every time I do a connection to the database, but it also offers me great portability. If I used a DSN-less connection w/ the data server's IP address, then each time I wanted to connect, a request would go out to the DNS server to resolve the address. That happens over the 1.5 mb/sec connection. And then, the data would be returned to my web/app box over that same connection, whereas if I ask for it on the subnet that they are on together, all communication happens at 100mb/sec.
Now I might consider using the IP for the subnet, and then I'd get the same speed using a DSN-less connection, but then I would lose the portability that allows me to develop on my internal development servers (using the same DSN name), and then just stick the exact same scripts on the server, with no modification whatsoever.
Now an argument could be made that I could re-do my internal IP addresses to match the ones in the office to the ones at the datacenter, but add to that the fact that using a DSN is quicker and easier than the DSN-less connection, and I'm going to stick with DSNs. I just like them better.