Oh yes. I am so sure that your test plans include such unlikely things as your customers deciding to run your app on a Pentium III with no SSE support. That's when you discover that the compiler settings are defaulted for SSE support. Or you discover that a shared memory file is being used by an old software version and a new software version at the same time, resulting in disagreements about exactly what should be locked when. Or maybe you find out that if a customer opens more than 1024 file descriptors your app starts to get silent memory corruption and eventually crashes. (POSIX, select(), FD_SET with fds higher than FD_SETSIZE). Did you check every single POSIX resource limit before using the system libraries? Did you do it correctly?
You can have 100% test coverage and still fail in the real world because of issues with the hardware, libraries and operating system.
You surely must realize that the real world contains so many possible ways to break software that you can't possibly test them all. At some point you just have to go for it.