Well I don't know about anyone else, but I've been using the heck out of
them. Take example function Foo()... now say there are two utility
functions used by Foo() to wrap some recurring activity: Bar() and Baz();
In C++ I would have declared them such as:
UINT uFoo_Bar(UINT x, UINT y);
UINT uFoo_Baz(UINT x, char y);
UINT Foo(UINT x, UINT y, char z);
Simple enough, sure... but note the ugly names on the utility functions,
used to avoid symbol conflicts. In D, I get to toss the ugly names, and
declare these three functions as:
uint Foo(uint x, uint y, char z)
{
uint Bar(uint x, uint y) { ... }
uint Baz(uint x, uint y) { ... }
...
}
The avoidance of ugly naming alone seems to make it useful to me. Plus the
encapsulation of Foo's functionality entirely within itself, by making the
utilities internal.
--C. Sauls

Another way of asking this questions is "what problem does 'nested
functions' solve?".
The common usage for nested functions is to clarify the written code for
the human reader. It can do this by allowing the author to write only one
copy of otherwise repeated code. The concept may also be used to highlight
a specific algorithm used by the enclosing function, without causing scope
issues.
For example, a routine might need a specialized 'maximum' function. By
isolating this special function inside its calling routine, the author can
make sure that the reader is alerted to it in a convenient manner. Also, if
this special function(algorithm) is needed multiple times in the enclosing
routine, the code becomes easier to read, due to the fact that repeating
code is replaced by a call to the special function. All this happens
without causing scope clashes with other routines.
Smart compilers may even inline these nested functions.

also in all class objects are by reference does this not include the
possibilty
of accidental corruption of dat.

In C i would sometimes find out i have a couple of similar lines in a
function, so i would write a macro to shorten them and reduce the
probability of a typing mistake. Then i would undefine in
t at the end of a function. That IS UGLY. And you sometimes can't
encapsulate this common parts into a separate function, since you need
implicit acess to local variables, and passing them would make your code
even uglier!
That's where nested functions are handy. Also consider that a
preprocessor is to be avoided/ isn't directly available with D.

also in all class objects are by reference does this not include the
possibilty of accidental corruption of dat.

Sure. But the D's object design is to make inheritance safe, which is
also supported by implicitly virtual methods. Now, consider the
alternative: you make objects stack-handled. This means that whenever
you pass an object elsewhere, which is a descendant of declared type, it
gets truncated and dies with a painful death. And you get Montezuma's
Revenge.
-i.