I think this is the issue: # trivial_acl: true. I am guessing that when Truenas made the home directory it ran chmod and nuked the ACL. You can prove ACL inheritance is working as you expect via the command line by making a subdirectory and some files by hand under home_dataset, and see that they get the right permissions.
If this is correct, your present best option for multi-protocol access is to make the home directory yourself and not allow TrueNAS to change the permissions. You can also set aclmode=restricted to prevent setting trivial ACL if you are only sharing via SMB. Setting aclmode=restricted is presently incompatible with Mac NFS clients, which treat fchmod() failures as a hard failure – I have filed a bug with Apple.
Can you also please consider voting for: Implement zfs aclimplicit to control granting implicit privileges to change file ownership and ACL as without this there is no way for you to prevent users from changing ownerships or ACLs. If you also share files via NFSv4 this can happen accidentally when a client runs mv or cp -p. In particular for shares via NFSv4, you will also find that by default all files are executable which is probably not intended. You can set zfs aclinherit=passthrough-x to prevent this, or set 2 ACL: one for directory inheritance which include executable bit, and one for file inheritance that does not.