Does a binary executable have to have some critical plain-text components?

Ultimately, the CPU runs the code. And the CPU expects instructions in "clear text". You could envision some application code where a small initial part of the executable first decrypts the rest of the code, but this has several issues:

• This forces all the code to go to RAM instead of staying on disk and be loaded on-demand, implying a higher RAM consumption and longer start times.
• That "decryption" routine must, necessarily, not be encrypted.
• The decryption routine knows everything needed to decrypt the rest of the code, so it can be decompiled and emulated by the attacker; it is not really "decryption" since there is no key (or, equivalently, the key is embedded in the routine, which the attacker has under his hands).

Experimentally, this kind of encryption does not hinder attackers much, so the general wisdom is that it is "not worth the effort". Unless you are in a very specific scenario where the "attacker" is a mindless automaton which may be fooled by these hide-and-seek methods -- that's the case of virus, where the "attacker" is the antivirus software.

Really encrypted code is possible if the CPU is doing the decryption itself, internally, with some key management. That's what happens in a PS3 console, for instance.

You are talking of two different components. One is the loader, which is not human-readable but must be machine-readable (therefore unencrypted) in order to be executed. And this has to be this way, as you say: otherwise you'd get a chunk of unexecutable data.

Several other "plaintext components" may also be present such as copyright, manifest, file info, and so on and so forth, which are human readable but are not sensitive - i.e., the developer couldn't care less if you are able to read his name. Actually he probably prefers it that way.

The loader performs several tasks of self-integrity checking, debugger-checking, and what not, and then decrypts the "true" executable in memory.

The extent to which the executable is encrypted depends on the use case. For example the binary might only keep encrypted certain critical routines having to do with copy protection, customization, or branding; so that you can open the file with a binary editor and see all the resources, strings, cursors etc. plain as day.

Or it could be encrypted with a standard "binary-agnostic-so-I-will-just-encrypt-everything" executable packer/encryptor, in which case you will see in plain text the strings belonging to the decryptor code, but not those of the original executable. Of course, decryptors are often further obfuscated to make it harder for your average hacker to recognize the encryptor and obtain the suitable decryptor (which, the more diffused the encryptor, the more it is likely to exist).