That only helps if the new process is being launched by an existing
cygwin process. If you launch the cygwin app from windows (e.g. via a
shortcut), then you're completely at the mercy of the system $PATH
value. In many cases, you don't WANT to add the cygwin directories to
the global PATH -- what if you have two (or more) separate cygwin
installations? Which one gets the preferred system PATH entry? What if
you switch between cygwin and msys? or cygwin and interix? Having a
cygwin DLL dir in the global $PATH might interfere with the operation of
those other environments.
By putting (most) DLLs in the same directory that (most) cygwin EXEs
live in, we leverage the Windows Runtime Loader behavior that FIRST
looks in dir-of-EXE for any linked DLLs, before searching $PATH.
The original idea to keep the DLLs in /bin was to allow running Cygwin
applications from a non-Cygwin process without hassle. A typical
example is CMD. You can simply chdir to C:\cygwin\bin and run `ls'. If
/lib contains all the DLLs, this will break unless C:\cygwin\lib is in
%Path%.
Also, you can't just create a bash shortcut on the desktop, unless you
really know what you're doing (set the start directory in the shortcut
to C:\cygwin\lib). When moving the DLLs out of /bin, you add some new
hurdle to using Cygwin.
Without this problem, or if we decide to ignore this problem, I would be
all for moving DLLs to /lib or /lib64.