Token-based authentication is not about securing the communication against third party attackers. It is to secure the server against the client himself.
For proper security you need SSL anyway. Without SSL, imagine an active attacker, e.g. that funny-looking bearded geek sitting two tables from you in the same restaurant -- you don't know it, but he has a fake WiFi access point in his backpack, and he is currently intercepting your Internet traffic, which you believe to go through the restaurant "free WiFi". That guy can hijack your communications at any point. He sees what you send to Web sites and what you receive from these sites, and he can alter both kinds of data at will. When he chuckles and almost gags on his milk-shake, that's because he is reading your emails.
To defeat active attackers, you need something which protects the data confidentiality and integrity, and makes sure that you talk to the right server, not to the Bearded-Geek-in-the-Middle. And that "something" is SSL.
With SSL, you can indeed just use HTTP Basic Authentication. This will work... provided that you want to use HTTP Basic Authentication, because that authentication is handled by the Web browser, with its own popup, which can be ugly. For instance, it may look like this:
Most Web designers are appalled at the sheer practicality and minimalism of this popup, which is reminiscent of the glorious architectural experiments from the Stalin era. Therefore, almost nobody does that. Instead, Web sites implement their own "login page", in pure HTML, and therefore cannot benefit from the inherent support of Basic Authentication by the browser. They must use a cookie, i.e. the "authentication token" which we are talking about.
Moreover, user authentication is not necessarily based on a login and a password. Some sites do funkier things, including delegating authentication to another server, using the OAuth protocol. This very site, security.stackexchange.com, does that. This again calls for some storage of data on the client browser, data which is not a login and password.
Once you begin to store data on the client browser, you may envision to store data that should remain opaque for the user himself (should he be inquisitive enough to have a look at his cookies), and which resists modifications from the user (depending on the data and what it's used for). This calls for, respectively, encryption and checked integrity. That kind of "securing" is all about storing things in the client system but without trusting the client system.
