Tempdb should be some % size of Large Database in SQL Instance ?

It doesn't seem like that!!!

There is NO any arithmetic formula to calculate Tempdb Size. Yes ?

Do we have any ?

Yes. still we can calculate/figure out by performing the following things when storing Intermediate results

1. Memory Spill - Causing by Hash Or Sort operation
2. Rebuilding Index along with SORT_IN_TEMPDB Option
3. DBCC CHECKDB on Larg Database
4. Using Temp (#/##) Table
5. Using multiple aggregations with huge data

Tempdb doesn't behave like User Databases (Say suppose, If the User database grows up to 500 GB and It'll remain same even the SQL Instance restarts. Right ?

But, The Tempdb will be recreated with the Size to whatever the size it was last set to!!!

To avoid Memory Spill:
- Omit the ORDER BY clause if you do not need the result set to be ordered.
- If ORDER BY is required, eliminate the column that participates in the multiple range scans from the ORDER BY clause.
- Using an index hint, force the optimizer to use a different access path on the table in question.
- Rewrite the query to produce a different query execution plan.
- Force serial execution of the query by adding the MAXDOP = 1 option to the end of the query or index operation

Is always good idea to use Temporary Table ?

No. Its NOT

As far as I know, Sometimes using Temp table improves performance and Sometimes Its not!

Creating a Temp table to hold intermediate results forces SQL Server to interrupt the data pipeline through a query to persist the results to disk.

Sometimes just doing one query rather than pre-aggregating or pre-sorting can be way more efficient and lead to far lower run time and tempdb usage!

So, "Always not good using Temp table to have intermediate aggregations/processing before resulting it"

It has to be compared with various methods with/without Temp table/CTE/table variable before implementing it in production environment!

So, Its not the case always do something Or always not to do something.

Importantly, make sure to pull only the data that's really required and create Non-clustered index after the table populated when using Temp tables to gain proper statistics created on that with actual loaded data!

Also, Creating more Non-clustered Index that aren't actually being used also causes the slowness on loading data and retrieving as well!

So, Non-clustered index to be created only based on the query plan actually using. 

There is no point of pulling Millions of records which is even not needed at all. Right ? But, Its happening most of times which can lead to enormous Tempdb usage!!!

Date and time SQL Server last started - How to...

1. When was the SQL Server Service Started ?
SELECT sqlserver_start_time [SQL Server Started at] FROM sys.dm_os_sys_info
GO

2. When was the TempDB database Re-Created ?
SELECT create_date [Tempdb Re-created at] FROM sys.databases WHERE [name] ='tempdb'
GO

Both the query have some difference on it's Time, Because, The Tempdb database will be Re-created after the SQL Server service started.

So, The first one tells the actual SQL Server start date & time

Backup and restore operations are not allowed on database tempdb

1.Tempdb is re-created every time SQL Server is started so that the system always starts with a clean copy of the database.

2.Temporary tables and stored procedures are dropped automatically on disconnect.

So, Backup and restore operations are not allowed on tempdb