"As a general rule of thumb, just set Maintainer
to the team; there might be some exceptions, like in situations where
the package is so complex that a check from a knowledgeable person is
welcome before an upload but they are very rare."
This is pretty much what I mean, but I think we should strengthen it a bit from what I think the current case is. Namely, if someone does an RFS for a package with themselves set as the Maintainer, the reviewer should encourage them to put the team there instead. Maybe reviewers are already doing that, although I don't remember seeing it.
If the request for a new version has been open for 2 years, waiting
another couple of months to confirm that the maintainer doesn't object
isn't really going to make much difference - particularly if that's 2
months of release-freeze time.
It's two months in which someone has to e-mail Thomas B several times, and in which what I've done will fall out of my memory. Maybe I'll forget about it by April, and someone will end up redoing the work. Maybe my laptop will kick the bucket in the meantime, and the changes that I couldn't commit to the centralised VCS will be lost. (Although in this case, they're in my PPA )
It's two months of release freeze time for Debian, but my understanding is that submitting to Debian experimental remains the preferred way to get new versions into Ubuntu. Ubuntu is not currently frozen, but in two months time it will be, so it will miss these changes for another 6 months.
Finally, it's two months as a minimum. Elena contacted the MIA team at least seven months ago, but Thomas B's packages have not been orphaned. That suggests that either they didn't follow up, or that he made contact but hasn't resumed any maintenance. I haven't seen any way to check on that, or to know the fate of my message to the MIA team.