Here's the thing. It's based on how the application works or how it was developed. It usually stops there. You can't blame Linux (or in this case, any unix-like OS) for those things. You'll find some applications out there that say the password can be in cleartext OR hashed in say, sha256. This is normally for compatibility reasons, as you may find out later in something else you may learn to setup.
You bring up Samba, and that's a good example of a situation where you think you could have an encrypted password or maybe a "store" where the passwords sit. That is not the case with Samba. What happens with Samba is when a client is communicating with a server or a workstation's share, it HAS to send the password in clear text. The CIFS daemon nor the Samba server can perform encrypted password exchanges. If the connection is encrypted, then you are somewhat "fine" in this regard. Newer versions of the SMB protocol do allow encrypted connections.
However, keep in mind too, files that have credentials (like config files) should be heavily dropped in permissions (say 600). A samba mount that always needs to be there on boot and put in /etc/fstab can be pointed to a "credential" file. It's cleartext, but can sit in /root, which means no user can see it. Only an administrator can, because /root is 700.
But again... this is based on the application you've installed or you're setting up. Look at OpenLDAP for example. When you configure the directory manager's password, you have to use slappasswd. It generates a {SSHA} string that you use in the configuration. And the configuration files cannot be viewed by a non-privileged user. /etc/openldap/slapd.d is 750, the files are 600 down the tree.
Keyrings are very specific to the desktop environment you're in. GNOME has GNOME Keyring, KDE has KWallet, for example.
The "security" comes down to many other factors: File System Permissions, SELinux (if applicable), Firewall capabilities, chroot jailing (specific applications, bind is an example), application security, tcp wrappers, and much much more.