Working on an application - everywhere an enum should be is a database table instead.

Me: What happens when someone changes "rejected" to "approved" in your status table?

Me: What happens when you re-seed your database and the indexes for your types are different?

All problems, with no time or scope to fix!
USE A FUCKING ENUM

Status tables can be necessary if you have other clients that only can use a db query like many report generator applications.

We have that problem where the options are either to use a varchar for the status storing the text in each line, hard code the options in the report query forcing us to rebuild that ti of a new status is added or having a status table.

And if you have clients that need to het reports with statuses in different languages a table makes it easier

Let's say there's some simple logic somewhere in your application like:
if(item.status.description == "Approved")
Or
if(item.statusId == 1)

Storing those values in a db where they can be changed means your code no longer works as expected.

Rule of thumb: if you don't want the values changing or adding to at runtime, don't allow them to!

You can't 100% guarantee that database values will always remain the same in the wild - you can guarantee that with enums

That's why I bias toward removing the dimension tables altogether. If the only time the table get written to is when a feature is added, using an enum ensures only programmers can alter the purpose of the values.
If your enum says 1 = Approved, and your DB only stores the int value of the enum, you've protected your application from a user/uneducated admin arbitrarily altering either the description of 1, or the int value of "approved"

From then on, records with statusId 1 can only ever be interpreted by your application as approved, since the textual value of that is fixed, and the logical purpose of 1 remains the same.

I'm not saying there's never a reason to use dimension tables, but if you intend to drive critical logical processes by the ids then an enum with a string value extension does everything you need, while protecting your code from faults beyond your control.

Incidentally, the approved/rejected example was a bad one - use a boolean isApproved for simplicity!

Ah, this is true for solutions where you're allowing applications to connect to the db directly - this is a saas solution, so all clients access data via a controlled WebAPI, which we control.
Using an enum allows you to provide meaning to a status id without the risk of that meaning being changed at runtime.

If a user needs to add their own then it's a totally different feature - you're storing more than a key value pair anyway since you need a user (or account) id stored too.
There are no other departments to worry about - we produce and analyse all our own ops intelligence, and we produce the reports for business analysis anyway so that's not a concern.
I don't see why you'd produce recurrent maintenance jobs that require a textual representation of an int anyway, so that's no concern either