what is a good use case for splitting user table by role
What you are describing is an example of the general situation entity sub-typing.

There are two basic ways to handle entity sub-typing:

One method places common attributes in a table and distinct attributes in separate tables, linked using 1:1 relationships to the common table.  Some other considerations:


The common table may have a partitioning attribute, which is a field that indicates which sub-type of thing each record is.
The primary key of each sub-type table is a foreign key to the common table.
You can create views which merge the columns from the common table and each sub-type table, so that for querying purposes you appear to have a "one stop shop" for each sub-type of thing.  This can simplify your queries since it leaves you one less join to write out each time.
This approach makes it easy to apply referential integrity if you have child tables that apply to only a single sub-type (or all sub-types).


Another method is to place all attributes in a single table, and then use declarative constraints and/or triggers and/or application logic to enforce sub-type specific business rules.  In this case:


A partitioning attribute must be used to indicate which sub-type of thing each record is.
This makes queries easier, but it spreads your business logic out in a way that many people will find confusing and undesirable.
This approach can lead to many nullable columns, which makes some people itchy.
This approach doesn't help you if you have child tables that apply to individual sub-types, but it is the only sane approach if you have child tables that apply to multiple, but not all sub-types.  


In your case you could pick either approach.  Which might be better depends on your preferences and on exactly how many distinct columns there are per sub-type.