You have it the wrong way round. Much like Access-Control-Allow-Origin the purpose is to allow other systems (in this case specifically web-hosted Flash and PDF content) to access your domain. The "remote domain" is you, the "source domain" is who we're defending against.
When clients request content hosted on a particular source domain and that content make requests directed towards a domain other than its own, the remote domain needs to host a cross-domain policy file that grants access to the source domain, allowing the client to continue the transaction. Normally a meta-policy is declared in the master policy file, but for those who can’t write to the root directory, they can also declare a meta-policy using the X-Permitted-Cross-Domain-Policies HTTP response header.
By default, all cross-domain requests will be blocked by Adobe's software, the same as browsers block cross-domain XMLHttpRequest.
An unwanted policy file may find its way onto your site, either by accident or malice. The purpose of adding X-Permitted-Cross-Domain-Policies in this case is to override it, so that the client still blocks unwanted requests.
Microsoft Silverlight uses a different policy file format, but it may also still use this header.
If you allow people to upload files, or are concerned about intruders using a different flaw to get files onto your server AND the content on your domain should not be accessed via other websites possibly trying to impersonate you, then yes X-Permitted-Cross-Domain-Policies will provide a security benefit. The attack is less relevant these days, as any user of modern software first needs to be tricked into allowing Flash or active PDF content.
If your website is just a regular website with nothing that requires a login to access, then you don't need it.
