There are two possible definitions of events here and they should be treated differently.
If you’re talking about a DDD event within a domain, I would go with the two distinct events. Domain Events should indicate something significant is happening and needs to be addressed. There’s an expectation that something within the domain will handle that event appropriately. When you create a Domain Event, you should have a handler specifically in mind. Note that this means if there's code that needs to handle any state change regardless of new value you would also need the UserStatusChanged.
If you are talking about what events to store in an Event Store, I would go with the generic UserStatusChanged. These events should not incorporate domain logic, they only reflect state changes in your domain. If you limit to UserBecameActive and UserBecameInactive you are implying those are the only two states that are significant. I understand those are probably the only two states that exist at the moment, but what happens when a third is added (such as “Membership Pending”). Do you now add a third event? What about the code that doesn’t care what the UserStatus value is, just that it changed (caching algorithms come to mind)? For Event Store Events, you do not need to have a specific handler in mind.
Event store events should say “something changed” not “something changed to an important value”. That’s up to the domain to decide.
Domain events should say "something significant is happening" regardless of whether that involves a state change or not.