According to this there are compelling reasons for caution when installing obfuscated binaries. Knowing this, how can running binary blobs as a part of the Linux kernel be acceptable from a security point of view? There exists a blob-free version of the kernel. The motivations behind that project seem to be primarily ideological. But what kind of risks do users of non-free driver modules actually face? Can a binary blob contain a rootkit designed to take over or open a backdoor into the entire system? How could such a backdoor be detected?
if you are interested in a 100% FOSS (free and open source) operating systems,
The main reason they incorporate binaries is for speed. A binary will be much faster than other code, so it's handy since it's so deeply built in to the kernel especially.
How can this be acceptable? Because it is assumed that they were not made with malicious intent. If you are truly worried about this, you can compile the kernel from scratch yourself so you can vet the code that goes into these binaries yourself. The second part is making sure that they havent changed to something thats unknown.
By non-free driver modules I assume you mean something purchased for use on the system. They are exactly the same amount of security as anything proprietary. Meaning that you don't know what's inside them and so if you trust the manufacturer of the software then great! let's hope they didn't feel malicious before they compiled down to binary.
Could a binary be designed to rootkit a system? Absolutely!! This is the same point I just made. Even a seemingly harmless binary could have a replica made that did the same thing and also was a rootkit.
How could such a backdoor be detected? Several ways. The best answer is file integrity monitoring. Even something that takes a simple MD5 or another simple one way hash of simple locations like /etc or just each of the binary files to make sure that someone hasn't changed them. And of course the usual suspects like antivirus, antispyware, and a good firewall.