This all seems quite common sense now I've had a think about it, but I know it was puzzling some people so on that basis I thought it worth posting. The scenario is HAT filling up with Dehydrated instances of the Isolated adapter, that have to be manually terminated.
If you look at the 'Activation Time' of these instances, they should correlate to the first time a web service was called after the IIS worker process was recycled (by default IIS sets this to happen every 29 hours, though of course it can be done manually as well) - there should be one instance per web server, per application pool accessing BizTalk.
When the worker process restarts (on the next request) it registers itself with BizTalk creating a new Isolated adapter instance, but doesn't un-register itself when terminating, hence the build-up over time.
In our scenario we have a pair of web servers hosting two Orchestration proxy web services, one that is called on a frequent scheduled basis and another that gets called on an ad-hoc basis by a Siebel workflow - a single application pool is used, which gets recycled every day at 4am.
Due to the use of 'sticky' network load balancing the first web service is normally processed by the same server, resulting in this server's Isolated adapter instance being created a few minutes after the scheduled recycling time.
The second web service is next called when users start accessing Siebel, which is typically around 8am, so the second Isolated adapter instance is activated somewhat later than the first.
We've currently disabled automatic recycling of the application pool, and are monitoring the w3p.exe process to make sure we don't get caught out by a memory leak-type issue.