Short answer: the advantage of using a dedicated selinux user for each service is the increased security / separation of privileges it enables. On the other hand, it is an invasive change which is not applied by default on most Linux distributions.
For this reason services often run with a dedicate user account (ie: httpd) and they are further restricted in what they can access/listen via dedicated selinux profiles, but without involving specific selinux users/roles (ie: httpd_t runs with the system-default system_u user role rather that a dedicated one). This is done to increase system security without being too invasive on how normal users work.
Long answer: the key difference is the one between Discretionary Access Control (DAC) and Mandatory Access Control (MAC)
The first (DAC) is the traditional unix permission system, where a user can change the permission of all files it owns. Moreover, an application is entitled to do any operation granted at the "normal user" level (for example, listening on an high TCP port). While very intuitive and reasonable, DAC itself leave open the door for misconfiguration by the user (ie: inadvertitely giving access to a sensitive file) or malicious software (ie: a buffer overrun which launch a shellcode opening a listening port for remote control of the target host).
Enter MAC, where only the system administrator mandates the rules of what can or can not be done. For example the sysadmin can, via selinux, restrict which files the user (who own the files!) can change, or what files can be the "other" bit set. In a similar manner, an application can be barred from listening on anything than a restricted set of ports irrespective of the default unix permission system.
From here, it is easy to see how a specific system can be all-in on DAC or MAC. In the first case the user has total control on what it can do, bar the things traditionally restricted to root. A "plain" (read: with no selinux/apparmor/grsec/whatever) linux system is a good example of a DAC-only setup. At the other extreme, on a MAC-only system any user can potentially be a privileged one without really having any possibility to interact with sensitive information (in such a system, only a specifically designated "true" root account can modify the MAC policies themselves).
That said, DAC and MAC are effectively orthogonal: they can be (and often are) both used at the same time to strengthen the overall system security. This is the key reasoning behind the targeted selinux policy: as transforming Linux in a MAC-only system would be too invasive (and really unneeded for 99% of cases), RedHat ships a policy which selectively applies more restrictive rules to the most sensitive services, leaving interactive users mostly unaffected. This is why users are, by default, assigned to the unconfined_u selinux user in turn has system_r and unconfined_r roles.
