Since this is mainly a matter of opinion, I'll give you mine, with the caveat that both approaches you outline will work.
I've learned the hard way to always go with the FK into another small enum table. Moreover, that enum table should be a proper table, with its own id. So the setup I'd recommend is:
id | Value
1 | HIGH
2 | MEDIUM
3 | LOW
With table ImpData's Priority field = 1, 2, or 3.
For sure, this entails a slight performance hit and increase in query complexity as you'll need to add a join each time. So why do I recommend it? Because I've found that as a project grows, what begins as a simple Enum often ends up becoming a complicated record in its own right. Maybe you want to add additional values, or change a value. Or maybe this value starts getting displayed on a website, and then you'll want to have different language versions for the same priority, plus specify which color to use for each one. In a few months, you may need to add a priority field to another table, and want to use the same Enum to make sure everything is consistent.
All of these things are super easy if you have a proper table, with a proper PK, and proper FK relations. OTOH, if you start with a simple constraint check, you're depending on the fact that your schema will never change. Maybe that's true if you're dealing with some legacy DB that hasn't changed since the COBOL days :-) But if you're starting a new project, I'd vote for flexibility in your schema over a slight performance hit any day.
A compromise would be to avoid using a PK and just make the values themselves the PK. The main benefit of this is that the value is right there in the ImpData table, and so you can see it easily and avoid a join. The downside is you can never have duplicate values. That might sound like a pretty safe assumption (and in this case, it probably is). But you never know when Murphy's Law will hit. In this case, you've set your PK on English words. You better hope there aren't synonyms in other languages that you might need to differentiate in the future :-) For example, maybe in French, two different priority levels end up mapping to 'HIGH' in English. Or maybe you want to have 7 different colors to indicate different priority levels, but on a text-interface, you want to map them into only 3 different words (LOW, MEDIUM, HIGH). If you have a separate PK, this is trivial to deal with. If you use the English values as PKs, you have a problem.
Admittedly, these are contrived examples, but hopefully you get my point. You never know what will be needed from your DB in the future, and keeping things as flexible as possible (when it's feasible to do so without drastically increasing complexity or performance issues) is, IMHO, the better option.