This is standard behavior. It will add the permissions you set to those folders, but marks them as child permissions.
Go to a subfolder, and check its permissions, and you'll notice those permissions are greyed out (child permissions).
If you want to have the child objects not have these permissions, you'll have to edit the first child folder and correct the permissions.
Usually a network system administrator will suggest to have a subfolder with no childs created and apply the new rights to that folder, then move the files that should have these rights there. This way, any subfolder will have the same rights and you don't worry about child objects not having different access rights.
Because if you deny a user to enter this directory, and you allow that user child directories, they will not be able to get there unless they manually enter that address. Only a person who knows that directory exists and how to manually get there will have access, something not many do. (which is why security settings are set to all child folders when changed, because it usually needs to have those permissions all the way down to the last child folder.
I don't have a Windows 10 system near me to check at the moment, but I'd guess just unsharing the folder would probably be sufficient.
Also note that share permissions do not override filesystem permissions. So, if the Users directory has share permissions of Everyone: Full, but the filesystem permissions are configured with more restrictive permissions such as Everyone: Read, Administrators: Full, Creator/Owner: Full, then the more restrictive permissions between the two are effective. So, in that scenario, the Everyone group/security principal is restricted to read only. Furthermore, if a subdirectory under Users has no permissions at all configured for the Everyone group/security principal then "Everyone" can see the subdirectory, but they can not open or read it.
On a side note, I'm not sure what best practices you've been reading, but unless something drastic changed in Windows 10 that I missed, the built-in administrator account (the one with a RID/SID ending in -500), can not be changed to a "standard user" account. It will always have administrative permissions.
The best practice I'm familiar with is to disable the built-in account (though it is still usable in safe mode should you ever have an emergency situation where you need it), rename it, create a new standard user account named "Administrator" which is also disabled (just to throw off would be hackers), and then create an administrator account under a different name for your own use.
UPDATE:
Per the conversation in the comments I realize you're referring to the default user created during installation. Not the built-in administrator as I misunderstood you to be speaking of. That user can be converted to a standard user as you stated. My apologies for the confusion.
As for the default permissions, I've stood up a test Windows 10 Virtual Machine (Anniversary update 1607) and found that the Users directory defaults to Everyone: Read/Execute/List. However, all the profile directories (Users\someone) under the Users directory are set to NOT inherit permissions from Users and are set explicitly to SYSTEM: Full; Administrators: Full; Profile Owner: Full. So, no one other than admins and the user who owns that profile has permissions to read, list, or change anything under another user's profile directory.
So, to reset your permissions to the defaults:
Unshare the Users directory
Reset the file system permissions for the "Users" directory (security tab) to Everyone: Read/List/Execute; SYSTEM: Full; Administrators: Full; Users: Read/List/Execute
Change any user profile directories under Users directory to not inherit permissions from the parent directory (security tab -> Advanced) and then explicitly set the permissions to SYSTEM: Full; Administrators: Full; <user name>: Full
These steps can of course be accomplished using PowerShell commands and such, but in the spirit of keeping things at your experience level and help you learn the ropes, I'll stick to the GUI methods. Here are some screen shots to help.
Users directory:
Individual user profile directory permissions (note that the permissions are NOT inherited)
Best Answer
This normally happens when you assign permissions to the file/folder level, but not the share itself. The two have separate sets of permissions.
ICACLS works on files and folders, so I would assume that the share is still set to Everyone RO, which is the default.
You can view the Share permissions by:
Once you set that, you should be good to go.