If there's a directory in the search path where someone you don't trust could write files, then the directory should not be in the path, period.
The order only matters if a command is present in more than one entry in the list. So the only case to consider is when someone trustworthy arranged to have one entry shadowing another, deliberately or not.
If it was deliberate, then the order should be to search the directories in order of local management: typically this means first ~/bin or equivalent if running under an account that has such a directory (not applicable to most system accounts), then /usr/local/bin, then the directories managed by the package manager /usr/bin/ and /bin.
In principle, there should not be any shadowing between sbin and bin directories. sbin directories are for commands that are only useful to a system administrator (this is why these directories are normally not in the path of users other than root). In principle there could be a command name for which you want to run a different executable as root, so sbin directories should be ahead of the corresponding bin directory — otherwise …/sbin/foo would never be executed since it would be shadowed by …/bin/foo for everyone.
The only case when there is an ambiguity is if there may have been accidental shadowing. In that case there isn't an obvious answer. Generally, it doesn't make much sense to put /usr/local/bin after /usr/bin: if you don't want the local administrator's choice of commands, then don't put /usr/local/bin in the search path at all (and remove /usr/local/lib from the library search path, etc.).
Between /usr/bin and /bin, in principle, one might want to shadow an executable from /bin (small version for boot time only) with one from /usr/bin (large version from a separately-mounted /usr partition), but tiny root partitions with a separate /usr are a very uncommon practice these days. It was a more common practice in the days when operating systems used significant disk space, but even then shadowing utilities in /bin with versions from /usr/bin was uncommon. The other order, putting /bin first, has a slight performance benefit (/bin is usually a lot smaller). On most systems there's no strong reason to prefer one order over the other. (On some systems /bin and /usr/bin are the same directory, but you shouldn't assume that unless you only ever work on recent versions of one of the distributions that do this.)
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin (or PATH=/usr/local/sbin:/usr/sbin:/sbin:/usr/local/bin:/usr/bin:/bin) is usually the right setting for jobs running as root, and PATH=/usr/local/bin:/usr/bin:/bin for jobs not running as root. I don't see any good reason to deviate from that (except for the /usr vs. / inversion) except to cater for local variations (e.g. a site-specific directory on *BSD distinct from the packages installed to /usr/local). Security-wise, it doesn't matter, but functionality-wise, putting /usr/local ahead of /usr and / is either indifferent or necessary.
