What are the pros and cons of using my customer codes as a primary key?

Pros - It is the natural key, it makes sense and it will likely be searched on, I presume?

Cons - The default behavior (which is totally changeable) is for a primary key to be the clustered index. An alphanumeric doesn't make the best candidate because inserts can cause page splits because they aren't set on an ever increasing value like an identity column. The Int identity column will take less space (4bytes) compared to the character data (40+bytes for the unicode) . This makes your other indexes larger since the clustered key is part of them. If you ever change how you identify your customers and make customer codes, this all breaks - going with a surrogate insulates you from those type of changes.

In this situation, I tend to optimize for the insert performance and go with an identity column more often than not for the clustered key and primary key. I really like integer clustered indexes. (Now I know your question was not about clustered index, it was about primary key... You could still choose some other column to be the clustered index and make this your primary key, you could also put a unique constraint on this and treat it as a natural key but not make it your primary key).

I would at the very least index this with a unique constraint and treat it like a natural key. I just don't know if you really need to make it your primary key.

Kimberly Tripp is a trusted resource who has a lot to say about primary keys and (more so) clustered keys on her blog - https://www.sqlskills.com/blogs/kimberly/guids-as-primary-keys-andor-the-clustering-key/

This is all just my opinion - YMMV.

Your value makes a good primary key, but a crappy clustering key. I'd put an identity column on the table for the clustering key, allowing you to use your big string as the primary key. This allows you to use your key value as the primary key and the identity as the bases of the clustered index.

What happens when your customer FOO, Inc. changes its name (gets bought out by another company like Northwest Airlines which is now Delta, or like Accenture which used to be Anderson Consulting)? You have to change all instances of "FOOINC" to something else, and if that's your primary key and there are other tables that have foreign key references to it, you've bought yourself a ton of headaches.

Bottom line: don't do it. Primary keys should almost always be integers - just auto-incremented identity fields where the index itself is purely for the use of the computer, so it has no intrinsic value related to the problem domain.