According to Five Simple Database Design Errors You Should Avoid by Anith Sen, using a common-lookup table to store the possible statuses for an entity is a common mistake.

Why is this wrong?

I disagree that it's wrong, citing the example of jobs at a repair service with many possible statuses that generally have a natural flow, eg.:

1. Booked In
2. Assigned to Technician
3. Diagnosing problem
4. Waiting for Client Confirmation
5. Repaired & Ready for Pickup
6. Repaired & Couriered
7. Irreparable & Ready for Pickup
8. Quote Rejected

Arguably, some of these statuses can be normalised to tables like Couriered Items, Completed Jobs and Quotes (with Pending/Accepted/Rejected statuses), but that feels like unnecessary schema complication.

Another common example would be order statuses that restrict the status of an order, eg:

1. Pending
2. Completed
3. Shipped
4. Cancelled
5. Refunded

The status titles and descriptions are in one place for editing and are easy to scaffold as a drop-down with a foreign key for dynamic data applications. This has worked well for me in the past. If the business rules dictate the creation of a new order status, I can just add it to OrderStatus table, without rebuilding my code.