Recently I wanted to manage a central set of document templates associated with content types across a number of site collections. We also wanted to look at using content type syndication with content types that have a document template applied. Document templates need to either be stored in the site collection where the content type is defined, or in <SharePoint root>/Templates/Layouts (_layouts). By default when you upload a document template when you upload a template it gets stored to a hidden folder, _cts/<content type name>. You can also deploy a template to this location as part of feature that deploys content types. I did a quick experiment to figure out how these two models worked with content type deployment.
In order to centrally manage a single instance of a document template, the template should be deployed to the _layouts folder. By mapping a folder for the feature to the layouts folder for your document templates, the template will be deployed to the file system when the solution is deployed, and available to any site collection within the farm.
A couple of caveats.
If the template is instead deployed to a location within the site collection (for example the default location of _cts/<content type>), it will be placed within the content database, and the document template will be replicated within each site collection. For a blog on this approach, see the blog on managing document templates and content types with Office 365, Deploying a Document Template file in Content Type in a (Office365) Sandboxed Solution by Chakkaradeep Chandran. In the case of a no-code or Office 365 (or a sandboxed solution with an on-premise installation) you will need to deploy document templates to the site collection since you can't write to the file system.
If the document template is deployed to the default "_cts/<content type>/" location then the document template will be replicated by the content type publishing logic with the content type. Since the document template is replicated, a new document can be created based upon the content type in the subscribing site. If an updated version of the template is uploaded, then the content type hub will re-publish the content type and document template to all subscribing sites.
Another option is to specify an existing document (which must be a location in the site collection). If an existing document location is selected, then the content type will be replicated refering to the location in the content type hub. However creating a new document based upon the content type in this case will fail since the publishing logic will not replicate the template file, and the content type will contain a reference to a document template that doesn't exist in the subscribing site.(unless some other mechanism also replicated this library).
Generally I'd recommend avoiding using a library to contain the templates if you are using content type publishing. If you need a central repository and templates don't change often, then use layouts in which case a single copy of the template will be used by all site collections in the farm. If you can't deploy a farm feature, or you want to manage the templates through the UI rather than with a developed applications, then deploy the template to the default upload location (_cts/<content type>) rather than using a library to contain the templates, and the document template will be replicated by the content type publishing infrastructure. While I did not test the case of a cross-farm service, you'd clearly need to deploy the feature to all farms when using the layouts approach. I'd hypothesize that the content hub should still replicate templates in the case where they are stored to _cts location.
If you want to deploy a content type across a number of site collections without using content publishing (recommended approach is using a site scoped feature), then the _layouts approach is the only solution to make it easy for maintaining a single document template used by all of the site collections using the content type.
Thanks to Andrew Connell and Rob Bogue for input.