Strictly speaking indeed mutually exclusive columns are not desirable and can rather be considered wrong.
This is not to say that you should never do and that proper results cannot be obtained if you do "wrong".
It is not always worth complicating the modeling because of a detail to say that it did the "right". The rule by the rule is never good, it needs to serve a purpose. If a lot of experienced people maybe supported by studies follow a rule, there should be a good reason and if you can do the same without creating difficulties, do, but do not do it blindly without analyzing if it will not have a cost that can not or should not pay.
Separate data into other tables, normalize has a cost of development and processing to bring the information every time you need. Need to compensate to make this decision.
A question that must be asked to find another solution in case the columns are mutually exclusive is what happens if you use the same column for both data? In some cases this can become a problem, it can hinder development, it may require an extra field to say what is registered there. But it can compensate. It is not the most correct solution, but it is valid in some cases.
Another question that must be asked is what problem you will have by having nulls. There is a chain that says that no column should have nulls. This is radical, it sounds like academicism to me, but it makes some sense. I think null is a perfectly "valid" value (Ik, it means it is an invalid value, but it is valid to use to represent that). I don’t like him very much, I prefer to avoid him, but I wouldn’t rule it out, it might make it easier.
Note that in almost all databases (probably all mainstream) an unused (null) column occupies very little space - zero or one byte - so do not worry about the occupied space that today is no longer problem. The organization of the data is more important.
How much will impair the performance and development of your queries? Will the volume of queries be very large? Is this loss acceptable? Often it is, sometimes it is not. Denormalization conscious is a useful tool. It should not be abused, it rarely brings such important results but it should not be discarded because it is not the most correct. In some cases it is not a matter of denormalize, is not normalizing what wasn’t meant to be.
Only you, in your specific case, can say which one will be better in this case. And prepare yourself to have to change in the future. What can serve well one day may no longer serve in another. And this is one of the reasons to use DRY and have canonical codes to access the database. So you need to change in only one place when the modeling changes.
The most important thing you’re doing, you’re questioning which is the best. If you don’t have much experience yet you have a chance to make a mistake but it will be a gain in some way, next time you may not make a mistake anymore. Or maybe you miss the other side because you don’t realize that the next one is a slightly different situation. It’s part of the learning process.
But if you want an "objective" answer that’s a little better than a heads or tails, normalize, implement the alternative you’re suggesting. But think about what is correct semantically, worry less about the mechanism. Try to see if the model asks to be normalized, if it is natural to have this column separate.