For small projects, having a JOIN table on identifiers has rarely any advantage over simply listing the identifiers in the programming language itself. This changes when you move to bigger systems and enterprise.
The primary data store of your enum values is suddenly not your database, but instead a system responsible for the list of values (small static tables), and each related system has the option to replicate a given static table to its own database. There are also multiple environments, clusters,...
Making a replication from one database to another (where the database engines are likely to even be the same, e.g. Oracle to Oracle) is a much easier task than making a replication in terms of database to programming language.
The latter most likely requires introducing logic to different programming languages (since different systems may use completely different approaches), ability to somehow commit to VCS the propagated changes, configuration of structural positions of such generated code,...
If your project is small, perhaps having the enums hard coded directly in the database may be feasible. But even then, it might be a better idea to store the enum names directly in the database, rather than storing arbitrary created and incremented identifiers decided only in your programming language of choice (e.g. storing
NEW instead of