Reason behind hashing the nonce in prevBlockHash? I understand the role that the nonce plays in the block header for calculating a hash for a valid proof of work.

But what I ask is: Do we consider the nonce in the prevBlockHash calculation of the previous block because, well, it's in the block header already (for the proof-of-work calculation), and it would be silly to write a calcPrevBlockHash function that calculates the previous block's header by ignoring the nonce?

Or is there a specific security property or assurance that we get when including the nonce in the prevBlockHash calculation of the subsequent block?

For instance, you could argue that we hash the timestamp because we want to capture the time that the block was generated. See answer here: Why the timestamp component of the block header? I guess you can argue the same for the nonce field.

But I claim that we could still have the nonce in the block header, and not hash it during the prevBlockHash calculation of the subsequent block, and things would still work. You would still be (a) able to validate this block, and (b) unable to mess around with the transactions in the block, because that would modify the hashMerkeRoot field, and thus render the block invalid.
Yes, you're correct. Without the nonce, we could still generate valid blocks.
However, to get a different hash we need to change the input for the hash. The input for the hash is the block header.

If there were no nonce, we would have to change something else about the block header for each try. That would only leave the timestamp or the Merkle root.  Other header items are fixed.
The timestamp is icky, because we would like it to show the actual time. So, we'd have to change the Merkle root.

The Merkle root calculated by hashing all transactions in the Merkle tree where they are listed. If we change e.g. the Coinbase or the order of the transactions in the tree, we could also gain another different combination to try. But to do so, we'd have to recalculate the Merkle root.

Rather, we put a nonce in the header directly that allows us to use the same block candidate for a number of different hashing attempts.

Hence, the nonce is used to introduce randomness into the blockheader. That's why it 

a) has to be changed, and
 b) has to be in the blockheader. ;)