Without pointing fingers at a specific app, there are several in particular that we have worked with who have "pretty URLs" for their website (e.g. "http://example.com/the-name-of-the-page") but their deeplinks are "ugly" (e.g. "example://page?id=123456"). There is no unified way here to derive the deeplink from the web URL or vice versa. As such, we cannot treat deeplinks and web URLs as always templatized; these are simply URIs whose identities should be considered arbitrary.
On another slightly relevant note, from the perspective of linked data and the semantic web, the <link> tag or "Link" header (both which are suggested by Google and URX) is meant precisely for this kind of reason: being able to link separate resources with a given relation (e.g. "alternate") who may have varying display/device/media qualities (e.g. media queries). Because semantic linkage is between two nodes of the web graph rather than DNS (which I guess would be a subgraph of the web?), one is able to use semantic metadata such as http://schema.org/docs/actions.html to describe not only how to access/consume a resource, but also alternate ways to do so (e.g. from an Android device instead of a desktop client).
Again the above isn't completely impossible to do with DNS, I'll give you that, but it simply is less tenable to assume template-like qualities of all URIs or to ignore the semantic implications of redefining how linked data has worked for the last decades.
On another slightly relevant note, from the perspective of linked data and the semantic web, the <link> tag or "Link" header (both which are suggested by Google and URX) is meant precisely for this kind of reason: being able to link separate resources with a given relation (e.g. "alternate") who may have varying display/device/media qualities (e.g. media queries). Because semantic linkage is between two nodes of the web graph rather than DNS (which I guess would be a subgraph of the web?), one is able to use semantic metadata such as http://schema.org/docs/actions.html to describe not only how to access/consume a resource, but also alternate ways to do so (e.g. from an Android device instead of a desktop client).
Again the above isn't completely impossible to do with DNS, I'll give you that, but it simply is less tenable to assume template-like qualities of all URIs or to ignore the semantic implications of redefining how linked data has worked for the last decades.