That's overly general. The unix APIs don't meet requirements if you need to reliably and safely reap child processes, and all of their descendants. And on linux, there are non-posix APIs that help in certain situations (pid namespaces and pidfds).

And for many, maybe most, applications, leaking a child process isn't really a problem.

Leaking child processes is inherently unreliable, it can lead to lots of issues in any non-trivial program, but even in the most trivial of programs it can lead to basic problems like accidentally fork-bombing yourself because you made a small programming error. There's no guaranteed way to avoid that, therefore to a lesser or greater extent, depending on the circumstances, it is not reliable.

The APIs are inherently unsafe, this is because once you are in a situation where you have leaked a process, you can't safely kill it without risking other processes. In some situations this could even be abused by an attacker to cause other problems.

So yes, in the most boring of applications where you have a user in front of a computer, there's no need for the reliability of processes having lifetimes bounded by the references held to those processes over their life. Likewise, there's probably no massive need for safety because if a process gets killed unintentionally, the user can fix it. But just because there exist circumstances where neither reliability nor safety are important, doesn't mean that the APIs aren't inherently unreliable and unsafe.

Furthermore, yes, linux has solutions for half of these problems, FreeBSD has solutions for other parts of these problems, Solaris has solution for other problems. The article calls out "the UNIX APIs" for a reason. The original APIs are as bad as the article says, and they have to be worked around with OS specific non-portable APIs. Which are, by definition, not "standard UNIX APIs" anymore.