It's good practice for every table to have a primary key. In most cases, this will be an ID column populated by a sequence or an identity column. This is the "safe" choice, though often unnecessary.

Code columns can make for good primary keys in limited cases. In my opinion, this is best when the codes are part of an external, widely used standard. ISO country & currency codes, and IATA airport codes are good examples.

Composite primary keys are often good enough for many-to-many junction tables, which only store the primary keys of the parent tables & perhaps some auditing metadata columns. They can also work well for child tables in master-detail relationships (orders -> order items, invoices -> invoice items, etc.).

That said, some frameworks expect all tables to have an ID column. If this is missing they can be tricky to work with. If using such a tool, mandating ID columns across the board is often the path of least resistance.