Most Unix variants allocate process IDs sequentially: 1, 2, 3, 4, ... When the largest possible PID value is reached, they start again at 1, skipping PIDs that already exist.
This is not an obligation. For example, OpenBSD assigns PIDs randomly, not sequentially; this is also an option on FreeBSD. The goal is improved security, though the benefits are dubious.
There is a (dubious) advantage to this behavior: it makes it rare for a process ID to be reused immediately after the process dies. There are many programs out there that monitor processes and assume that after a process dies, the PID will not be in use — which breaks if the PID is used by a new process. Those programs do have an excuse: there are no good APIs to monitor a process except from its parent. But such programs are widespread enough that OpenBSD avoids reusing a PID for a little while (a few minutes, if I remember correctly) after a process dies.
The main reason for this behavior is that it's how it was done on traditional Unix systems, and there's no strong reason to change. For file descriptors, Unix historically used the first free fd number, and that behavior has been made an official standard so all Unix/POSIX systems have to do it this way.