Try this: create an add-in for Excel/Outlook/PowerPoint/Access with a custom task pane. Run the solution, see the custom task pane. Open another Excel workbook, see the custom task pane. Now, create an add-in for Word or InfoPath with a custom task pane. Run the solution, see the custom task pane. Open another Word/InfoPath document/form, and... where's the task pane?
In essence, the custom task pane is always parented to a “doc-frame” window, not to the main app window.
In Outlook, it is parented to a window which in turn is parented to the window for the current inspector or current explorer. You can only see one explorer at a time. On the other hand, you can see multiple inspectors at the same time, and this is why in Outlook you can specify which window to attach the task pane to when you create it (so you potentially end up with multiple independent task pane objects).
In the other apps the task pane is parented to the frame window that hosts documents (whatever a "document" means in each of the other apps). In Access, Excel and PowerPoint there is only ever one of these frame windows per instance of the app. In Word/InfoPath there are multiple instances of this frame window, one for each doc/form you open. So, you can see that in Word/InfoPath, the task pane gets attached to whichever is the active docframe when you create it, and is not visible in any other docframe.
That's also why, when you instantiate a task pane in a Word/InfoPath add-in, it gets parented to the current docframe - and when you close that document, you also close the docframe and therefore the task pane.
So the behavior of task panes in Outlook explorers is essentially the same as the behavior in Access, Excel and PowerPoint. The behavior of task panes in Outlook inspectors equates to the Word/InfoPath behavior. For Outlook, Word and InfoPath, your likely approach is to watch for inspectors/documents/forms being opened and attach task panes to each as appropriate.
I've heard people say that this behavior is broken, but if you think about it it actually opens up some interesting new opportunities. For a start, it lends itself to producing app-level add-ins that are doc-context-aware. It certainly means that add-in developers need to be aware of the issues and design accordingly - but since when was that a bad thing?