At first, this comment of yours didn't make sense:

... different threads share single CWD, thus, for them not to step on each other toe, you're supposed to use absolute paths.

The issue of threads not stepping on each other seems unrelated to how file paths are specified; e.g. if two threads try to write to the same output file without proper steps being taken to control their timing, you have a problem, regardless of whether the file path was relative or absolute.

But then I found this little bit in perlthrtut:

Note that while threads themselves are separate execution threads and Perl data is thread-private unless explicitly shared, the threads can affect process-scope state, affecting all the threads.

The most common example of this is changing the current working directory using chdir(). One thread calls chdir(), and the working directory of all the threads changes.

Even more drastic example of a process-scope change is chroot(): the root directory of all the threads changes, and no thread can undo it (as opposed to chdir()).

Well, there are ways to get around that other than switching to all absolute paths all the time. Store your CWD path in a scalar variable (which, by default, is not shared across threads); use that variable together with file names when opening files; you won't ever need to do chdir(), but even if you do, using that path variable with file names will keep the thread behavior consistent with respect to files. If one thread needs a different CWD from others, it can change its own copy of that variable (or you can give it a different value when you start the thread) without affecting other threads. (And don't ever use chroot() with threads, not that anyone would...)

But a more important point is that threads can step on each other in various ways besides improper use of chdir and file paths, and absolute vs. relative paths have nothing to do with those.