The only limitation of the user.data service is how you can retrieve the data, since you can do it by:
For example, you can find all the values a module set for a specific user passing
$uid, or find all the values set by a module passing only
The data stored is serialized, though. If you need to index values using something else than module name, user ID, or a name assigned to the data, you need to create your own database table.
The pro of using the user.data module is that modules don't need to create the database table to store the data, and that the stored data is automatically deleted when a module is uninstalled (and in this case, all the data stored for that module is deleted) or when a user account is deleted (and in this case, all the data stored from the user.data service for that account, from any module, is deleted). This means less code for modules.
Entity fields aren't used to store preference, or information a module gather about users, but rather properties of the entity.
I would use the user.data service, except when it makes more complicated retrieving/altering the stored data. If I were to write a module that saves the IPs from which users access a Drupal site (including the first and the last time an IP was used from a user) to then check which users connected contemporary from the same IP, I would not use the user.data service, but a custom database table where each row contains user ID and IP, which allows to aggregate data and still be able to handle the information separately.
As for the database table growing quite fast, I would not worry about that, if using the user.data service is not causing data duplication. Using the previous example of storing the IP from which the users connect to a Drupal site, if the module is using
$user_data->set('mymodule', $uid, 'ips', $list_of_ips) to store the list of IPs used from a user and
$user_data->set('mymodule', $uid, "ips:$current_ip", TRUE) to quickly find the list of users using a specific IP with
$user_data->get('mymodule', NULL, "ips:$ip"), then that is something to worry (and a sign that a different approach is better).