Ah ha.  Right you are.  So we can only go on the available evidence.  Your charts (even with broken links ) and the pictures of the execution plans are enough to make me shy away from CTEs in this looping type of scenario.

Always the compromises: Ease of code vs. production performance.  The folks in Redmond don't like to talk about benchmarks.  It's groups like this where the authors take the time to write up a finding and readers contribute their experience that are of great benefit.

The intial issue with the Key Lookup in test case 2 was caused with a poor index. 

If the following index is added, the CTE is actually outperforming the loops in all cases for me.
I have used CTEs a lot, and with a little work, you can get them to almost always out perform loops.  Of course there are always the exception.

CREATE INDEX ix_Groups_ParentGroupId_IN_GroupId_GroupName ON dbo.Groups (ParentGroupId) INCLUDE (GroupId, GroupName)

The purpose of the "inlcuded columns" in the index is to remove the key lookup. In the test4 of the article, it achieved this by removing those columns (GroupName, ParentGroupName,ParentGroupID) in the recursive part. Though CTE method performance improved a lot, you can see the results were still favour to the Loop method.

I tested the way to eliminate the key lookup by creating inlcuded columns in the table as recommended by Newbie (thanks). On my server (which is different from that the original tests were taken), the results showed CTE can benifit more than the Loop from the new index and the performance is close to Loop, but it's still shy of it:

By CTE: Starts at 2007-05-10 09:30:23.563, Finishes at 2007-05-10 09:30:24.597, Takes 1033ms

I found the exact opposite on my dev enviornment.  The CTE procs out performed the loop procedures.  I used the scripts and ran through all the test scenarios and found the CTE ran 50% faster than the loop.  I'm running Windows 2003 Enterprise Edition, SQL 2005 Enterprise Edition SP2, 4 Dual Core (3.0 GHZ) Processors and 2 GB RAM. 

I also use Recursive CTEs in a real production environment (3.2 TB Database) on 200 million and almost Billion row tables with a hierachly data structure and many nodes.  I've never had an issue with CTE performance as long as indexes are tuned properly.  I would not shy away from using CTE just because of this article. 

set statistics io on
set statistics time on

declare @TopStructureID_in int

select @topstructureid_in =
	(select structureid
	from dbo.campaigns
	where campaignid = 560)

declare @Hierarchy table (
Lvl int not null,
StructureID int not null,
ParentID int,
primary key (lvl, structureid),
State varchar(3))

declare @Rows int

insert into @hierarchy (lvl, structureid, parentid, state)
select 1, structureid, parentstructureid, rowstate
from dbo.corporatestructure
where structureid = @topstructureid_in
and rowstate != 'del'

select @rows = @@rowcount

while @rows > 0 
begin

	insert into @hierarchy (lvl, structureid, parentid, state)
	select 1 + h2.lvl,
	c2.structureid, c2.parentstructureid, c2.RowState
	from dbo.corporatestructure c2
	inner join @hierarchy h2
		on c2.parentstructureid = h2.structureid
	where c2.rowstate != 'del'
	and c2.structureid not in
		(select structureid
		from @hierarchy)

	select @rows = @@rowcount

end

select *
from @hierarchy

set statistics io on
set statistics time on

declare @TopStructureID_in int

select @topstructureid_in =
	(select structureid
	from dbo.campaigns
	where campaignid = 560)

declare @Hierarchy table (
Lvl int not null,
StructureID int not null,
ParentID int,
primary key (lvl, structureid),
State varchar(3))

	;with Hierarchy (Lvl, StructureID, ParentID, RowState)
	as
	(select 0, StructureID, ParentStructureID, c1.RowState
	from dbo.corporatestructure c1
	where structureid = @topstructureid_in
	union all
	select 1 + h2.lvl,
	c2.structureid, c2.parentstructureid, c2.RowState
	from dbo.corporatestructure c2
	inner join hierarchy h2
		on c2.parentstructureid = h2.structureid
	where c2.rowstate != 'del'
	and h2.rowstate != 'del')
	insert into @hierarchy (lvl, structureid, parentid, state)
	select lvl, structureid, parentid, rowstate
	from hierarchy

select *
from @hierarchy