Bro, I recently joined a company where the "senior" developer joins DB tables by strings and puts order header info and the order items in the same table.

If you're joining, there better be an index (or else you have bigger problems in your DB design). Indexes are usually B-trees and can look up an item in 2-3 page faults and ~20 memory comparisons, regardless of how big the table is. The page fault time dwarfs the comparison time, so in practice it doesn't matter whether keys are strings or integers. (I guess there's potentially a space premium for strings that makes fewer records fit on a page, but remember that ints are generally 64 bits now. Anything less than an 8-character string will be smaller than the equivalent int, and 8-16 characters is within a factor of 2x.)

Putting order header and order items in the same table is weird, but could potentially be defensible if it saves you a join on common queries.

One problem with strings though is that they might, in the parent post's case, have been editable somewhere. In that case a user (admin user, for example) can unknowingly break the relation.

A short string code though, only available from a lookup, for instance, might be acceptable. Since you already have a lookup though, put an int column in there and use the int.

Joining by strings can make sense if there is a natural key. Often, for performance, you would use a surrogate key even if a natural key exists but there are rare times it makes sense.