It's interesting to look at the advantages they list, and see (1) which are also covered by Linux, (2) which are not covered by Linux but are of questionable usefulness, and (3) which are not covered by Linux and are useful--and then to see if these could be brought to Linux reasonably.

It's free software, so anybody can use, modify, and
redistribute it under the terms of the ?GNU General
Public License (GPL).

Linux already has this covered.

It's compatible as it provides a familiar
programming and user environment. For all intents
and purposes, the Hurd provides the same facilities
as a modern Unix-like kernel. The Hurd uses the GNU
C Library, whose development closely tracks
standards such as ANSI/ISO, BSD, POSIX, Single Unix,
SVID, and X/Open.

Linux has this covered.

Unlike other popular kernel software, the Hurd has
an object-oriented structure that allows it to
evolve without compromising its design. This
structure will help the Hurd undergo major redesign
and modifications without having to be entirely
rewritten.

Not covered by Linux. I wonder if this is actually useful, though. In my experience when something needs to undergo a major redesign in an operating system, it tends to be a whole subsystem that needs the redesign--so even if it were object oriented, you'd be redoing the design of all the objects for that subsystem. Sure, you would be able to keep, hopefully, the same interfaces to other subsystems--but you don't need object oriented design for that.

For example, in the filesystem area, I believe modern monolithic kernels have well-defined interfaces between the filesystem subsystem and the rest of the kernel, so major redesign of the filesystem subsystem could be done without affecting the rest of the kernel. Within the filesystem submodule, they have well-defined interfaces between the generic filesystem code and the code that implements specific filesystems, again allowing for major redesign within the filesystem subsystem or the code for specific filesystems without affecting too much other code.

The Hurd is built in a very modular fashion. Other
Unix-like kernels (Linux, for example) are also
modular in that they allow loading (and unloading)
some components as kernel modules, but the Hurd goes
one step further in that most of the components that
constitute the whole kernel are running as separate
user-space processes and are thus using different
address spaces that are isolated from each other.
This is a multi-server design based on a
microkernel. It is not possible that a faulty memory
dereference inside the TCP/IP stack can bring down
the whole kernel, and thus the whole system, which
is a real problem in a monolothic Unix kernel
architecture.

One advantage of the Hurd's separation of
kernel-like functionality into separate components
(servers) is that these can be constructed using
different programming languages -- a feature that is
not easily possible in a monolithic kernel.
Essentially, only an interface from the programming
environment to the RPC mechanism is required. (We
have a project proposal for this, if you're
interested.)

Linux does not have this covered. This is where it gets interesting. After all, even on a monolithic system like Linux, people have pushed some code to user space. A good example is FUSE. That's a kernel module that provides a bridge between the kernel filesystem code and user space code for specific filesystems.

I don't see any reason this could not be done for other things now in the kernel, such as the TCP/IP stack.

This would introduce performance problems, due to overhead of communicating between the user mode components and the kernel components, or between different user mode components, but microkernels like Hurd also suffer from that overhead.

To put it more succinctly, if you want a microkernel you don't necessarily have to start with a microkernel like Hurd is doing. Why not start monolithic with Linux and add microkernel aspects? It would be an interesting project to make a microkernel via a series of mutations of Linux.

It might be possible that way to end up with a kernel where you can choose whether each subsystem is handled in the traditional monolithic way, or bridged out to user-mode code, or both. You can then pick where on the performance vs. security spectrum you need to be for each aspect of your system, tailoring it to your particular requirements. That would be pretty cool--sounds like a fun project.

The Hurd is an attractive platform for learning how
to become a kernel hacker or for implementing new
ideas in kernel technology. Every part of the system
is designed to be easily modified and extended.

Hurd has the advantage here. Even a microkernel evolved out of Linux as I described above would probably be uglier to learn from.

However, I'm not sure this is important enough. There are systems designed for learning operating systems hacking, such as Minix. A potential new kernel hacker could learn on one of those, and then switch to Linux pretty easily.

It is possible to develop and test new Hurd kernel
components without rebooting the machine. Running
your own kernel components doesn't interfere with
other users, and so no special system privileges are
required. The mechanism for kernel extensions is
secure by design: it is impossible to impose your
changes upon other users unless they authorize them
or you are the system administrator.

Advantage Hurd. I question the usefulness. This would have been important in the time sharing days. Now we're for the most part the only user on our system--there's no one our changes could be imposed on! Also, if a microkernel-like Linux kernel were developed as described earlier, it would gain some of this automatically.

TL;DR version: most Hurd advantages over Linux either are in areas that aren't really important to most people, and for those that do matter it looks like they could be added to Linux.