When would ssh -t not be appropriate instead of ssh?
Using ssh -t instead of ssh for connections to remote servers has several advantages. For example, I can directly edit a file with vim: ssh -t host vim foo.txt, which would fail otherwise.
Are there any circumstances under which allocating a (pseudo)-tty would be a bad thing when using ssh?
When piping the input or getting the input back, which is the typical use of "ssh host command". Control characters could be interpreted by the TTY layer (^S for ex.)
Yes, sometimes you want to make a silent, backgrounded connection, for example when setting up a tunnel (e.g. SOCKS proxy). In such examples, you want the process to NOT have a tty.
Here's an example of setting up port forwarding from localhost to some remote host...
ssh -l username -fNTL 8073:server:873
After this has been set up, you can then rsync to localhost, instead of to the remote host, hence effectively, tunneling your rsync via ssh...
rsync --port=8073 -a me@localhost::myStuff /tmp/myStuff/
You'd do this say if rsync going out to server was blocked, but ssh wasn't.
In addition to the above...
(1) Different tilda escape handling:
The "~." escape will disconnect you if you have a pty (-t). For a long-running command, you might want to prevent someone from accidentally halting the process if they type ~.
$ ssh hostname.tomontime.com -t sleep 60
[type ~. and it disconnects]
Connection to hostname.tomontime.com closed.
$ ssh hostname -T sleep 60
[I type ~. and it treats it like normal keystrokes, which the sleep command ignores.]
~.
~.
Try the same thing with CTRL-C. You'll see that with -t you are sending the CTRL-C to the "sleep". With -T you are sending the CTRL-C to the ssh program running on your machine. There may be times when this makes a difference (i.e. the program handles INT differently than HUP)
(2) You just want to minimize the pty or network connection activity.
When trying to reboot a machine that is out of ptys you don't want to encourage the system to try to allocate a pty! This also minimize the network connections that will have to be closed (delaying the reboot).
This will work faster and more reliably:
ssh -T hostname reboot
This may have problems:
ssh -t hostname reboot
ssh -t creates a pseudo terminal on the remote machine. This is useful if you are chaining ssh commands thru multiple servers and want a real terminal on the far side (so you could use 'vi' for example).
You might NOT want '-t' when login scripts behave differently if there is a terminal. This is bad practice IMHO, but I've seen cases where a login script checks for TTY before 1) setting the prompt, and 2) expanding the path to many interactive applications.
In another instance (mentioned by TomOnTime above), I actually have run into cases where all the TTY (ptys) are used up. Obviously a mis-configuration, but no need to chew up a resource for a bunch of tunnels and rsyncs.