I cannot see anything "more efficient" in that new identifier.

Same size of the value, not very efficient process of generation, additional checks required to prevent duplications...

And it's all in sake of succession.

As SQL Kiwi (cheers mate!) said - evil is not in GUID, evil is in clustered key on GUID column. It's another extremely bad practice, so common that you'll say I should not challenge it.

But I still do.

You'll never select a range of GUID's, so it should be never used for a clustered index.

Problem with GUID's is not in lack of succession.

It's in architectural flaw of using internally auto-generated identifiers for global identification of business objects. No matter how smart will be your auto-ID it will never be good for the purpose.