And per project, I'll have a few. Say I have one where I have one shell for compilation, one for version control, and two for testing. Give each one a prefix for the project, and I've got all that separated out. E.g.: Two projects: foo and bar: foo-compile, foo-git, foo-test-a, foo-test-b, bar-compile, bar-git, etc..
Now, I have clean shell histories (and scroll buffers) for each. I can ssh into each one as I want, and reuse my terminal windows. This latter bit helps keep my already-complex-enough window setup manageable.
2. You work on a remote machine and prefer to have your window layout remembered there, so it can instantly be restored no matter what computer you're physically working on, whether or not it happens to have or even support your favorite tiling window manager.
3. It's simply easier for me to do everything within one terminal window full-screened on a 27 inch monitor. It's less context switching.
For 3, can you elaborate? How is it less context switching? You're doing the same set of operations in both settings - switching, moving and resizing terminal windows (whether real or virtual).
The two arguments I could see are resource usage (not an issue on modern machines) or detach/attach (which is a huge benefit when working remotely, but I don't see any gain locally). But other than those, I don't see any benefits to having a second tiling system sitting on top of my current tiling system.
(For reference, I use i3.)