Not necessarily. In scientific computing, it is common to encounter "embarrassingly parallel" scenarios where each thread can solve equal-sized chunks of the problem, and you can wait till all threads have terminated to collect results.
edit: Okay, the final wait is usually implemented with a lock under the hood. Nevertheless, this type of program is straightforward to reason about.
Certainly some systems (such as Java and multiple CPUs with independent caches) that use thread-local working areas, you cannot rely on a task being completed meaning that you can actually use the data it has produced, until you actually make use of a lock. The lock ensures that the local copy is synchronised with the central copy.
There's plenty of opportunity for fun if you don't use locks in some form or other in multi-threaded systems.
Oh wait.
The presence of a lock tells you nothing about whether a program is well-designed. In fact, the whole idea that you can argue about the correctness of a program from the presence or absence of "code smells" is absurdly simplistic. I have seen plenty of bad code littered with while statements.
Incorrect use of abstraction levels, such as using tools that are too low-level and error-prone for the task at hand (as in the majority of business applications) IS one of those warning signs. It usually indicates a conceptual problem, and makes the code needlessly complex.
Besides that, depending on the task, it's very important how something is implemented.
But wait, you don't use blocking-IO, you poll the sockets to see if there is data available, right? Do you realize what you are polling? (hint, it is global and mutable)
This type of program is an uninteresting corner case, that tells us nothing about the more general problem of reliably writing concurrent software.