Primarily, you are using navigation to structure
the user experience into something different from the
free-form hypertext browsing offered by the Web. You are asking
the user to focus on one section at a time, then go back
to the hub and navigate to another section. This
certainly reduces clutter on the "spoke" pages -- the user
has less to look at, and less to think about.
But by restricting the available navigation paths through
interactive pages, you can also prevent errors --
users can't shoot themselves in the foot so easily.
With no navigation buttons, they can't leave a Web form
half-finished by jumping to a different page (the "abandoned
edits" problem); with a modal window in a desktop app,
they can't "lose" the dialog on the screen; in
general, they have less opportunity to get the UI
into a self-inconsistent or confusing state.
Furthermore, restricted navigation means you have much tighter
control over what circumstances the UI needs to handle -- this
often results in simpler (and thus cheaper) implementation.
The architecture scales well, too; as more functionality comes
on line, it's easy for you to add more spoke links to the hub
Finally, you may simply want to design the user's experience of
the "spokes" as simple, self-contained UIs. This isn't always
appropriate -- in fact, it can be downright annoying! -- but the
choice is yours. An advantage is that the user will find it very
clear what to do; the hub-and-spoke structure is intuitively obvious
in many contexts. You click on a spoke, you do your thing,
and you go back to the hub when you're done.