As for roles, it's probably easiest to explain by using the ticket-tracker as an example: The roles here would be "Submitter" and "fixer". Possibly also "triager", if you have some person first who triages and does the assigning. And possibly a "QA" role, if you have a QA step at the end.
In the simple two-role submitter-fixer case, you'd have the "submit ticket" (okay, so submit probably wouldn't be a task, but still), "clarify problem" and "verify fix" tasks assigned to the submitter role, while the "fix" and perhaps some other task would be assigned to the "fixer" role.
The point is, you can group together tasks (transitions), and say "these tasks should all be done by the same person or group of people".
Another example: an RFP. The "vendor" does this, the "purchasor" does this, etc.
A very quick outline of what I envisioned with workflow: I want to let people build packages like the ticket-tracker, like bug tracker, or other packages that involve a workflow as a significant component, to easily build that, and get a superb user interface almost for free. How's that for a goal? :)
Another side goal is to make it super easy for packages that just need some really simple approval type mechanism to do that.
Hm. Very vague and hand-wavy. Will try to say something clearer some day.