Performance consideration or overhead having primary key with 3 GUID (Clustered Index)

During a database design there has been an interesting discussion that will there be any performance addition in adding a second non-clustered index on a Globally Unique ID (GUID) column that has already a unique clustered index.

IF needed you need to consider the usage of GUID column carefully, to accomodate the unique key across the database server having the GUID certainly fulfills this need, but it comes with a cost. Think about storage of having GUID Clustered  index as it is a wide column (16 bytes to be specific) and contains a unique combination of 33 uppercase and numeric characters (these are HEX value characters that range from A to F and numeric values that range between 0-9). So for the data if huge inserts are done on the tables, then the large size of the GUID's will contribute to page splits, potentially resulting in performance problems. In my experience another disadvantage is that typically, primary keys are searched frequently, further contributing to additional server overhead. Additionally the memory usage when GUID is called is heavy and that too querying the column values within a query will give tough time to performance (to DBA too). For instance such addition to storage bytes by this column and if you have assigned this as a primary key, is going to be stored in the clustered index (unless specified to be a non-clustered index), and will be the page pointer for each leaf page in a non-clustered index. Also, if a GUID is used instead of an integer identity column, then the binary rendering of 33 characters needs to be matched for each row that is returned using that column in the WHERE clause.

But there is a gain in having the table with GUIDs as a primary key that will create a default unique clustered index, so if you are going to create another non-clustered index in reverse order say GUID3 and GUID2 as another unique index the performance factor will have a boost, as by nature of GUID with this index creation that will result in fewer levels in the index tree. So regardless of whether the table has a clustered index, any non-clustered index on the table that is not declared as unique will have the locator appended to the index entries in the root and other non-leaf pages.

I believe having a int GUID as a surrogate key and then adding two unique indexes (GUID2, GUID3) and (GUID3, GUID1), this will likely improve performance since indexes will have a 4-byte clustering key instead of a 32-byte clustering key.