GUID vs BigInt vs Int for a surrogate primary key, or the leading edge of any index, is all about what you want the index/key to do. There is no "one is better" answer that's universally true.

GUIDs have a number of advantages and disadvantages. Storage space, index fragmentation, possibly bandwidth and I/O issues (because of size), and being extremely human-unfriendly, are some of the disadvantages. Close-to-guaranteed-uniqueness, the ability to generate them in the application layer without a database round-trip, lack of real limits on the number you can generate, are some of the advantages.

BigInt has one advantage over Int, in that it can store 18-pentillion values instead of 4-billion for Int. Rare that you need more than 4-billion, but if you do, BigInt will work and Int won't.

Int and BigInt have advantages over GUID in terms of size, sequentiality (partially handled by NewSequentialID for GUIDs), and human-readability. They have disadvantages in terms of range, uniqueness, and resource contention in heavy-insert databases (slight but real).

You need to determine what you need the column to actually do, what your expectations are on data volume in the table, and make an informed decision based on that, not just decide "BigInt is better".

On the question of composite clustered indexes/keys, it's rare that you'd get a significant performance increase by adding a surrogate key just to bypass a natural key. It can happen, but the reason to use surrogate keys is usually that you can't come up with a valid natural key (people, for example), not that you need to speed up table queries. Surrogate keys, like ID or GUID, are convenient for developers, but they have very little, if anything, to do with performance of queries.