The API works somewhat different from your understanding.
TL;DR: Think of the domain field as a “filter” that decides, if a policy is applicable to an action or not.
Query 1 creates the default policy for the token {id}. This policy applies whenever an action is attempted with this token and no more specific policy exists. Since the policy does not contain perm_dyndns or perm_rrsets, these permissions are not granted. So, this query effectively prevents the token from doing anything at all.
Query 2 creates a policy for the given domain. This policy applies whenever an action within this domain is attempted with this token. Since perm_dyndns is set to true, the token is allowed to do dyndns updates. Since perm_rrsets is not included, it is implicitly set to false. This policy does not say anything about what the token can do on other domains.
So in summary, the token can not do anything in your account, except on the domain {hostname}.dyn.example.com (and its subdomains), where it can do dyndns, but no other DNS changes.
The API docs have more detailed information:
https://desec.readthedocs.io/en/latest/auth/tokens.html#token-domain-policy-management
Side note: If you use PUT instead of POST, you can create new or change existing policies. This avoids the error message when the policy already exists and may be more to your liking.
Another note: There are a number of tools that can interface with the deSEC API: Tools implementing deSEC
I believe, the only one that supports token domain policies is this:
GitHub - s-hamann/desec-dns: A simple deSEC.io API client
It’s arguably slightly more convenient than using curl directly, but still requires a basic understanding of the API.