You have to think in a menu and remove the command line, at the beginning everybody will complain but it is the only way to close the security. A submit job could be a break in the security, all DLT* commands, also the remove, strsql strseu strdfu strsda could cause problems, the list is huge.
For a starter, I would secure Delete and Clear commands such as,
From a command line you can type in GO CMDDLT or GO CMDCLR, etc… and see all the different commands or just hit F4 and see the different type of commands you can choose from. You want to make sure they cannot delete or change system values, backups (Unless they are a system admin or operator). It really all depends on their job responsibility to what a person should have access to.
You might also want to restrict some people from using the STRDFU, STRSQL commands as well as CRTPF, CRTLIB unless they are programmers that as part of their job need this access.
If you do not restrict object level access to the production files, then the users can use the built in tools like STRDFU and STRSQL to manually change the data and then tracking changes to the production database is very limited and certainly frowned upon by your companies internal and external auditors.
You also do not want users creating libraries and files because if unchecked the users will manage to fill up the disk space quicker than anything. Another CLR not mentioned above is the CLRPFM (clear physical file)
There is no “best practices” set of commands to restrict. If best practices have been followed, then there is no need to restrict any commands — the users won’t have existence authority to any files, so you don’t care if they can execute DLTF for example since there would be no files they had authority to delete anyway. In currently supported releases, a command line won’t let them do any harm regardless of command if their authorities are appropriate.
Best practice is to apply object authority to give individual users and/or group users only the level of authority that they need and no more.