All shell and utilities must respect the code page tag on all files.

.Today, the appropriate z/OS UNIX Shells and Utilities respect file tagging when auto-conversion is enabled.
The example you cite (zopen openssh) are not part of the Shells and Utilities. They are a separate project.
Please open an issue in their git project.

The current state is, that a lot of programs opens files and assume an encoding that is not correct. maybe they convert to a certain encoding, but get it wrong because the source file is in a different encoding than they assumed or they assume a specific encoding and still get rubbish, because the source file is not in that assumed encoding.

You might be right, that for od, tag awareness wouldn't really do anything. For iconv it could ask "the file seems to be in encoding 'abc' are you sure you want to convert it from 'def' (y/n)"

All?  I don't think that you want that, since not all files are processed as text.

Your use cases all seem to have to do with using zopen openssh ssh-keygen keys with IBM z/OS openssh.    I don't understand why you would want to do that, but I don't see any reason offhand why IBM z/OS openssh ssh and sshd shouldn't support autoconversion for tagged text files containing keys.   
 

"All"?  some utilities are by design wisely exempt from autoconversion.
These include od, cksum, iconv, and others.

would it rely on autoconversion?  Would it be limited to ISO8859-1
and IBM-1047?

What about UTF-8, which abounds on desktops and web pages?

Would it be affected by locale settings?  On my desktop I see, e.g.:
504 $ echo aπz | sed -E 's/(.)(.)(.)/1 \1  2 \2  3 \3  /'
1 a  2 π  3 z  
505 $ 
505 $ echo aπz | LC_CTYPE=en_US.ISO8859-1  sed -E 's/(.)(.)(.)/1 \1  2 \2  3 \3  /'
1 a  2 ?  3 ?  z
506 $