An index scan can be faster because, presumably, the index doesn't cover the entire set of columns in the table, while a table (or clustered index) scan has to read all of the data. If an index does include all of the columns in the table, then it should be roughly equivalent to a table scan, and the choice between an index scan and table (or CIX) scan will be a coin toss. The difference is that when you have fewer columns in the index, you can fit more index rows on an 8kb page, leading to fewer overall pages you have to read in order to scan all of the data in the index.
To illustrate what I mean, imagine if you have two copies of the phone book, one with last name, first name, street address, and phone number, and one with just last name, first name, and phone number. Now imagine that because the street address doesn't have to be printed, you can fit two extra columns of names and phone numbers on any page in the phone book. The end result of this is that the phone book is thinner, because you can fit the same number of phone numbers on fewer pages. Next, imagine you are charged with counting the number of phone numbers in the book. Which would you choose, the one with the street address listed (which has more pages, analogous to a table scan) or the one without the street address (which has fewer pages, analogous to most index scans)? I would choose the one with fewer pages.
Another wrinkle in this is that some indexes can be filtered, meaning that not only do they have fewer columns in most cases (and therefore can fit more rows onto a single page), but they can also have a WHERE clause that eliminates a lot of rows. In this case, as well, an index scan will be better than a table scan (but this will only work for queries that have a matching WHERE clause and the same semantics).
In the updated question, it appears you are asking about the difference between a table scan and a clustered index scan. This can be vastly different from comparing a table scan and a non-clustered index scan. For the most part, a table scan and clustered index scan are about the same - in both cases you are reading all of the data in the table, just that in the former case the table is a heap. Depending on how much churn has happened in the table, a table scan can be worse over time - due to things like forwarded records. Plenty more details in this question:
What's the difference between a Table Scan and a Clustered Index Scan?
(Though the answers there don't seem to mention anything at all about forwarded records, one of the primary reasons I do not advocate heaps in any of our customers' environments. I would always want a clustered index on every table except for very specialized scenarios.)
