Multiple tables vs role-based authorization

Question

What is the use case for deciding to switch from role-based authorization to having separate tables for users? Is there a design pattern or convention that recommends when one approach is cleaner to implement/maintain than the other?

Details

I'm building a Rails 4.2+ application, but this question is not strictly Ruby/Rails, although if there is a convention for Rails I would like to hear what it is.

In this application, a client enters and submits data but also needs the ability to see the status of their submission as well as add additional info (docs, clarifications, etc...). That's all a client does: submit data, check the status of their submissions, and get email notifications. They can be associated to multiple accounts if the client decides to enter a submission to multiple accounts.

Staff, on the other hand, actually process the client's submission and are associated to a single account. It is also theoretically possible that staff could become a client and have their own submission.

The "view layer" for each type of user is very different, with each performing very different roles. This can be addressed with both multiple tables as well as with role-based.

However, the data for each type of user will be somewhat different.

For instance, a client enters personal information that goes into the "clients" table as well as several associated tables, and the client will be treated like a "contact" in the system.

Staff, on the other hand, will not need to have the same level of personal information in the system since that information is only necessary to process the submission. As mentioned earlier, though, a staff could potentially become a client, which if I did role-based authorization, would be a nightmare to implement.

Staff will also have additional authentication requirements, such as 2-step authentication (clients will not need this).

As I look at this application, what I'm really seeing are 2 distinct applications operating together: the client side and the staff side.

Most of the research and questions I've looked at seem to continually counsel using a single users table and implementing roles for authorization. This means I would have a bunch of conditionals all over the application, though. Most other developers even on SO (I came across several similar questions in my research) seem to look down upon multiple tables for users.