I am not aware of any problems that that a threaded build of perl causes for non-threaded applications, apart from a minor drop in performance.
As for writing threaded apps, bear in mind the following:
use the latest possible perl, ie 5.8.7; user-level threads only appeared in 5.8.0, and there have been many fixes in the minor releases that followed.
Perl ithreads are generally less efficient than forking; fork() uses the OS's memory-management facilities to do copy-on-write of the process's pages in hardware, while perl's threads->new() goes through the entire interpreter's data structures and copies each individual variable etc (only code is shared, not data).
Shared data in perl's ithreads is very expensive, both in terms of speed and memory usage. A shared scalar variable usually has a copy in every thread that uses it, plus a separate shared copy. When you assign to a scalar, the thread's copy is updated, then that data is also copied to the hidden shared copy. When you read from a shared scalar, the data from the hidden shared copy is copied to the thread's one. Thus if you have N threads all accessing a long string variable, your memory usage will tend towards (N+1) times the length of the string.
Shared arrays and hashes use a mechanism similar to tieing,
which means that they are slow, but not too memory-inefficient.
Try to avoid having complex, deeply-nested shared data structures