Most bugs you experience daily (Word or your favorite game/appp crashing, etc...) are caused by actual software errors in overly complex systems with many dependencies. Multithreaded-coding errors can often account for many of those, but not only, complex system with many layers and complex dependencies can often hide obscure behaviors that can cause crashes in a given machine if, for example, you have a weird combination of disk drivers, file system code, and an antivirus hooking and acting on every filesystem read or write.
When, for example, a Word plug-in makes a call to Word's object model, this goes through easily 10 software layers until it reaches its target, some of these layers being configured via the flaky Windows registry, others going through jumps from VM-based to native code using weird "marshalling" techniques, etc... in these cases, you may encounter buggy behavior in any one of the 10 layers, or in a combination of two of them, even if it seems like you are just incrementing a simple counter.
Most of the time, though, bugs are caused by the app's own code (your own code): careless code, dangerous practices, lack of solid control-flow design, etc... if you write really good code, it's unlikely you will have many support issues. Only if you are working in some problem-prone area: plug-ins to other complex, often poorly-designed products, code pushing graphics drivers to the max, etc... where you get into "complex system" behavior.
Even if you use multithreading, if you control all the code, you can write very solid code. If your multithreaded code is perfect, it won't crash. Although it can uncover bugs in third-party libraries, etc... which is why I tend to write only "worker threads" with no third-party dependency if multithreading is required.
And I think it's very dangerous to warn novice programmers to think that the bug is probably somewhere else.