Why does SSDT deploy inline FK Constraint as WITH NOCHECK?
There is only one kind of foreign key constraint (though it can be trusted, or untrusted).

If it was a new table, both code paths are essentially the same. But they do it this way because SSDT is taking into account it might need to tweak the DDL to add to an existing table. 


If the table existed and it altered the table with check, the deployment will fail and will not put a check constraint on the table.
If the table existed and it altered the table with nocheck, leaving the check for afterwards, you'll get an error if old data doesn't meet the criteria, but at least the schema change will be in place.


What they've done is generate a consistent set of code that covers both non-existing and existing possibilities. They haven't tried to optimise for every use case. 

Essentially it has no further inherent meaning. It's just an artefact of how they output the code.