Say you want to add a new status called Imported for issues which are newly added, but came from some other database instead of being added by hand.

So you change your code from:

if (newStatus == IssueStatus.New)
{
// send a “new issue created” email
}

To:

if (newStatus == IssueStatus.New || newStatus == IssueStatus.Imported)
{
// send a “new issue created” email
}

Then you find some other place in the code that also needs to change:

if (newStatus == IssueStatus.New)
{
// create a record in the issue billing system
}

…becomes:

if (newStatus == IssueStatus.New || newStatus == IssueStatus.Imported)
{
// create a record in the issue billing system
}

That conditional expression for the if statements is duplicate code!

So if you’ve used a strong type IssueStatus, instead of a string, you can easily add a property to your IssueStatus class:

public bool IsNewlyCreated { get; }
// make it true for New and Imported, false otherwise

Then refactor to:

if (newStatus.IsNewlyCreated)
{
// whatever
}

Suddenly your if statements become much more expressive about _why_ the code block should be run. If we choose the property names well, then the code is not just saying “if status is X or Y”, it’s telling you the business meaning behind it. And if we choose the property names well, we should be able to come along in future and add a new status called Z, set its properties appropriately, and existing code will already understand it.