There are many reasons that using roles is better than using long playbooks, and very few reasons that using a single long playbook is better than using a role. These are almost always clear only at a certain scale. Team size, workload number and complexity and frequency of execution all come into play here and the larger any of them get, the more obvious it becomes that organising things hierarchically and modularly into roles is the right thing to do.
From the Ansible docs, there is an emphasis on re-usability:
Roles are ways of automatically loading certain vars_files, tasks, and handlers based on a known file structure. Grouping content by roles also allows easy sharing of roles with other users.
This is also why Ansible Galaxy is potentially useful. One can summarise the effect of a long list of tasks, into a single concept - a role. Although the role may be considered as simply a long list of tasks -- and so not that different from a playbook -- the main benefit comes from the way it scopes variables. Out of the several analogies which may be applied, one may use the Object Oriented analogy. A role is like a class. The usage of that role, applied in a playbook, is like the instantiation of a class into an object. If you consider object-oriented programming useful, you will consider object-oriented infrastructure provisioning useful.
For me, however it comes down to testing. A playbook is tactical and is useful in specific situations. A good role is strategic and is written to solve general problems. Since good roles are modular, they should contain unit tests for various scenarios to prove to the downstream user that they do indeed solve the more general problem, as well as making it clear what is actually covered in the tests.
Typically roles should be maintained, with proper documentation:
- what variables do they use ?
- what scenarios are they written for?
and wide coverage:
- several base operating systems
- several deployment scenarios (docker, AMIs, bare-metal, etc)
and organise tasks cleanly:
- use tags
- dynamically import tasks based on execution conditons and user-provided variables
In short, I wouldn't consider it a fair comparison to compare a bunch of playbooks with the usage of different roles. When it comes time to refactor your playbooks into something maintainable, you will need roles.