Sugiro que você não esteja vendo o benefício do pedido porque a tabela de destino não tem PK. Então, é a sobrecarga de conversão que você está vendo. SE tiver um PK, as 585k linhas ainda devem ser classificadas na inserção. Como o SQL sabe que é semi-ordenado?

Agora, se foram inserções de 5.850 x 100 linhas, você poderá ver algum benefício porque as novas linhas ficarão "no final" e não "no meio", reduzindo assim as divisões de página e a sobrecarga.

Eu iria mais longe e diria que o artigo é datado de 2002, e é para SQL 2000, e foi ultrapassado pela vida real.

No SQL Server 2005 temos GUIDs SEQUENCIAIS para permitir que GUIDs estritamente monotônicos resolvam alguns problemas. O GUID como PK também foi feito aqui:exemplo recente:INT vs Unique-Identifier for ID field in database with 3rd party links.

Se um ORM determinar o GUID como um PK em vez de uma chave natural ou chave substituta padrão baseada em int, isso é uma limitação severa do ORM. E um caso do rabo do cliente abanando o cachorro do banco de dados.