Nested procedures like that do make sense in this XML related code of the original question.
To process all nodes, a recursive call of ProcessNode is needed.
But you have to note that sometimes, inner functions need to access a lot more data than a few parameters.

Potential implementations may be:

  • Use "flat" procedures, as in the naive rewrite of the Stack Overflow's OP;
  • Use "nested" procedures, as in the original implementation;
  • Create a dedicated class (or record + methods) which will remain private to the implementation part of the unit.

Of course, the 3rd option sounds the more maintainable.
It will allow clear separation of the process, and allow the use of variables local to their methods.
Using a record (or an object for older versions of Delphi) will allow the processing object to be allocated on the stack of the main procedure, so you won't need to write
 Obj := TInterType.Create; try .. finally Obj.Free.
But if you use an object please note that some new version of Delphi has compilation issue - you should better use record with methods.

The "flat" procedure style is IMHO not better than "nested" procedure, and even worse, since it would need to add additional parameters to the inner calls, or use some global variables.
By the way, having a lot of variables for every call will increase stack space, and reduce speed.

The "nested" style is in fact OOP oriented. When an inner function is called, the compiler pass the caller stack base in a register to the nested function (just like the additional self parameter of an object). So the inner function is able to access all the caller stack variables, just as if they were declared in a private object (the 3rd solution).

The Delphi IDE and internal debugger handles nested procedures quite well. IMHO it could make sense for some small piece of code (that is, something that can be read on the same screen height). Then, when you need more process, a dedicated record/object with methods and explicit variables will be more maintainable. But the "flat" option is IMHO not to be coded.

In mORMot source code, you will find some nested procedure calls, and some dedicated private object, when it deals with recursion algorithms within methods/functions.
For instance, here is how we implement an optimized Quick Sort algorithm in SynCommons.pas, for the QuickSortRawUTF8 procedure. Even the pivot is allocated in this implementation, to let the stack be as small as possible.
Code is still very readable and maintainable, IMHO.

type
  /// used internaly for faster quick sort
  TQuickSortRawUTF8 = object
    Values: PPointerArray;
    Compare: TUTF8Compare;
    CoValues: PIntegerArray;
    Pivot: pointer;
    procedure Sort(L,R: PtrInt);
  end;

procedure TQuickSortRawUTF8.Sort(L, R: PtrInt);
var I, J, P: integer;
    Tmp: Pointer;
    TmpInt: integer;
begin
  if L<R then
  repeat
    I := L; J := R;
    P := (L + R) shr 1;
    repeat
      pivot := Values^[P];
      while Compare(Values^[I],pivot)<0 do Inc(I);
      while Compare(Values^[J],pivot)>0 do Dec(J);
      if I <= J then begin
        Tmp := Values^[J];
        Values^[J] := Values^[I];
        Values^[I] := Tmp;
        if CoValues<>nil then begin
          TmpInt := CoValues^[J];
          CoValues^[J] := CoValues^[I];
          CoValues^[I] := TmpInt;
        end;
        if P = I then P := J else if P = J then P := I;
        Inc(I); Dec(J);
      end;
    until I > J;
    if L < J then
      Sort(L, J);
    L := I;
  until I >= R;
end;

procedure QuickSortRawUTF8(var Values: TRawUTF8DynArray; ValuesCount: integer;
  CoValues: PIntegerDynArray=nil; Compare: TUTF8Compare=nil);
var QS: TQuickSortRawUTF8;
begin
  QS.Values := pointer(Values);
  if Assigned(Compare) then
    QS.Compare := Compare else
    QS.Compare := StrComp;
  if CoValues=nil then
    QS.CoValues := nil else
    QS.CoValues := pointer(CoValues^);
  QS.Sort(0,ValuesCount-1);
end;

In all cases, do not be afraid of creating some internal objects/classes to implement your algorithms. The latest versions of Delphi allows even private types in class definition - but sometimes, I feel more confortable with making the internal object totally private to the implementation part of the unit, i.e. non even appearing as private members of the interface part of the unit.
Classes are not only meant for publishing your process outside of the unit: OOP applies also to implementation patterns. 
Your code will be more maintainable, and in most case, the self parameter will be used to refer to all associated data at once, so your code may also be even faster and lighter!

Feedback and comments are welcome on our forum.