VSTO with Windows Form and Worker Threads

I have an Office addin (Outlook if it makes a difference) created with VSTO. The addin creates a Windows Form at startup. My Form creates several threads. I'm looking for either concrete guidance or peoples' experiences with what safely works for the following situations:

1.) A thread created by the Form needs to access the Office object model (Globals.ThisAddIn.Application)

2.) A thread created by the Form does not need to access the Office object model, but does need to update a control on the Windows Form (the Form was created by the addin or 'UI' thread as I sometimes hear it referred to)

For 1.) above I've taken the following https://msdn.microsoft.com/en-us/library/8sesy69e%28v=vs.120%29.aspx to mean that it is safe as long as you set the thread's apartment state to STA and you handle exceptions. But http://weblogs.asp.net/whaggard/all-outlook-object-model-calls-run-on-the-main-thread seems to imply that in .NET VSTO, calls to the object model from any background thread are safe as they're automatically marshalled to the main thread for you, and making the 'background' thread STA is merely for performance reasons. Is that all there is to it?

For 2.) Is there any problem with letting the 'thread' be a Task or a IsBackground thread, provided it uses the control's InvokeRequired/Invoke pattern? Or does it need to be a STA thread doing the Invoking?

Update I've seen several VSTO experts mention not to touch the Outlook object model on anything other than the main thread and that in Outlook 2013 it will actually throw an error if you do it. I have an add-in that does in fact access the Outlook object model on a couple background threads (system.timers.timer, background thread) and I hadn't seen such errors in my log. Then all of a sudden a couple days ago, there was a span of about 10 minutes where my addin's error log was full of the following errors:

The application called an interface that was marshalled for a different thread. (Exception from HRESULT: 0x8001010E (RPC_E_WRONG_THREAD))

After this 10 minute span, the errors mysteriously disappeared, and I hadn't made any changes to the code, both immediately prior to the errors and immediately after the errors. Prior to that, I'd been running the addin for months on my machine (primarily in cached connection mode, if it matters) without seeing any such errors.

I'd love if someone could point me to the Microsoft documentation where it says not to access the object model on background threads.

Outlook Object Model on a secondary thread is definitely not supported. Don't remember if they said anything officially, but I personally heard that from several Outlook Product managers.

Extended MAPI (or MAPI wrappers such as Redemption) is the only way to access Outlook data from a secondary thread.