First - one needs to remember that there have been a lot of tempdb optimizations that have already been applied - so.....many of the RDDB options may not be all that applicable....
For example, you need to remember, that tempdb already has a ton of stuff to optimize it....going back to the 12.5's, if you did a select * into #temp and the select could use parallel worker threads, ASE would partition the #temp under the covers and do the bulk inserts in parallel and then unpartition the table (there was a trace flag that a lot of sites enable to prevent this unpartitioning due to perception of system table contention at the time...while it did add to it, the partitioning so rarely happened it wasn't the main cause). Then in 15.0.x, ASE added lazy IO's......and then delayed commit was essentially enabled by default for tempdb. Then 'session tempdb log cache' was added - which avoids logging altogether if the txn log records fit within the session tempdb ULC size - something most DBA's forget to enable. I don't understand that....it is kinda like throwing away free money.
The problem with RDDB and minimal logging is that it makes it IMPOSSIBLE to rollback transactions correctly. There are times when this is necessary.....remember, tempdb is used for a lot of system stuff other than default for #temps. For example, fully prepared statements are in tempdb - as are work tables/store indexes, etc. Also, you need to be really careful - think of what would happen if tempdb was only an IMDB and it filled up.....how would you fix it??? Remember, if tempdb fills, even common procs such as sp_who stop working - so you couldn't even get a list of spids to kill hoping to clean up #temp tables.
However, of course, you *can* create your own user defined tempdb that is both IMDB and minimal_logging if you wish. Creating your own tempdb really isn't that hard to do. SAP does this by default - they create a saptempdb for all users and leave tempdb just for the system stuff and LWP's that are created from all the prepared statements. It really is much much safer that way...and something I encourage. Leave tempdb for system use and sa_role stuff when critical recovery is necessary - create your own tempdb (or more than one) and bind users to it. It really isn't all that difficult.