It's not dumb, it's just low level. Just like theads. Applications should be programmined in application level programming languages providing higher level notions such as monitors or actors, not threads and fork(2). A forking operation, at the appplication level, is a semantic operation that must be processed explicitely and specifically by the application (by each object having underlying threads).
The proof that the problem vs. forking is not threads, is that the worse example given in the article referenced, that of file I/O, occurs as well in processes without threads (or "single-thread" processes if you want): if you write to a file from both the parent and the child, you must take precautions at the application level. This has nothing to do with threads.
It's much less of a problem in a single-threaded program because no other threads can be running at the point where you call fork(). So there's no worry about a mutex being held (assuming you don't fork with a mutex held, but don't do that), and you can know exactly which files are open at that point in time.
The proof that the problem vs. forking is not threads, is that the worse example given in the article referenced, that of file I/O, occurs as well in processes without threads (or "single-thread" processes if you want): if you write to a file from both the parent and the child, you must take precautions at the application level. This has nothing to do with threads.