TSM restore performance is an implementation problem not a product problem.
Everyone wants to take the default installation or command for everything.
Tivoli supports multi-threaded restore by separating your data appropriately
into filesystems/spaces and then you can multi-thread restore.  The issue in
years past has been that TSM might have to mount a lot of tapes to perform
the restore.  But with features like collocation by filespace or node
properly implemented you get the best of both worlds.  Much better backup
times than Veritas backup times overall because of the incremental nature of
TSM.  Yet, the number of tapes is dramatically reduced.  I promise you TSM
single file restore times of the previous night's backups are going to slam
dunk every other product on the market if you use a disk pool of the proper
size.  The good news is that V5.1 is supposed to do intelligent mult-thread
restore to improve restores.  I will go back to what I have said before.
Veritas only performs well on full restores, but in a DR scenario you will
never be able to create the copies of tapes necessary to do this when you
have 100s of servers.  This is where TSM shines and the sun sets on Veritas.
A restore is only as good as the backup you restore from.  Veritas causes
you to sacrifice good offsite copies because of the hardware requirements
and time to create the duplicate copies.  The most common thing to do is
send offsite last week's full backup, not the current one.  TSM can easily
provide the current one.