When I worked for Sybase I asked the same question. :)
But yes, you're right, the recoverability argument doesn't quite apply for tempdb for any transaction that's entirely within tempdb. Imagine though a scenario like this:
begin tran
insert database2..table1 [...]
insert #temptable1 [...]
insert database2..table2 [...]
commit tran
If we'd thrown away the tempdb log pages (or never preserved them in the first place) you can see we'd have gaps in the sequence of anything we'd want to roll forward or roll back. Now you might say couldn't we just skip the tempdb bits? Yes... but then we're getting into one codeline managing transactions in tempdb and one for everywhere else. Messy, and another opportunity for bugs.
We might also have a persistent table in tempdb (ie a regular table, not a #table) which we've put triggers on... and the special "inserted" and "deleted" tables in triggers are materialised from the transaction log. I grant you this is a special case and not likely to happen very much, but still it has to be catered for. Likewise replication (although replication in or out of tempdb is a bizarre and foolish idea), likewise referential integrity.
That said, recent innovations have recognised we don't really care quite as much about transactions in tempdb, and so there are some under-the-hood performance improvements to how logging works in tempdb only.
Another factor - tempdb is actually recreating on ASE startup from the model database. Model has a transaction log because it is the tempate used for *all* new databases. Again we'd need one template for tempdb database(s) and another for everything else. Much cleaner to just treat the databases the same.
There are quite a few things we can do to speed up logging in tempdb (specifically, rather than just tempdb performance overall). As Jan_Franek has already said, separating data and log just like you would for any "real" database is almost always a good idea, and it lets you do other sneaky things. If you're on any of the regular commercial UNIX varieties, you can put tempdb data on raw partition and tempdb log on file (with dsync off). If you *really* want to squeeze the last drop of performance out, there is a delicious hack to put tempdb's transaction log into its own (small!) ASE named cache. (Normally you can't put tempdb system tables into their own cache, only the entire tempdb database, but there is a trick to do this. It will only gain you 2-3% and only in a very busy server with plenty of memory to play with.)
But yes, bottom line, while it does indeed seem like we could dispense with logging in tempdb, but it turns out there probably are good reasons to keep it. :)
