This thread in the Biztalk.General newsgroup</a> explains some of the dynamics behind MSMQT operation and also makes clear why the active/dehydrated instances of MSMQT receive locations stay in the HAT tool once all orchestrations and messaging instances have finished with it. To quote the important part in this regard:
Second, InReleaseT. Because MSMQT needs to guarantee ordered delivery, at any point in time only one thread on only one computer in the group must process messages that are delivered to a specific queue. This thread works on some persistent data that is saved and loaded from the database. We call this a MSMQT instance. When the thread is running on a specific computer, we say that the MSMQT instance is “Active”. When the data is persisted in the database and there is no one working on it we say that the instance is “Dehydrated”. An active MSMQT instance maintains a lock on the queue object in the database, so that no other active instance on any other computer can work on this queue. For load-balancing purposes and to save memory, active MSMQT instances are dehydrated if the queue wasn’t used in a while.
Good to note this information comes straight from the horses mouth.