MAC vs DAC vs RBAC
DAC is the way to go to let people manage the content they own. It might sound obvious, but for instance DAC is very good to let users of an online social network choose who accesses their data. It allows people to revoke or forward privileges easily and immediately. Reactive access control, Seeing further and Laissez-faire file sharing provide nice examples of research on DAC with users.
RBAC is a form of access control which as you said is suitable to separate responsibilities in a system where multiple roles are fulfilled. This is obviously true in corporations (often along with compartmentalization e.g. Brewer and Nash or MCS) but can also be used on a single user operating system to implement the principle of least privilege. RBAC is designed for separation of duties by letting users select the roles they need for a specific task. The key question is whether you use roles to represent tasks performed on your system and assign roles in a central authority (in which case RBAC is a form of MAC); or if you use roles to let users control permissions on their own objects (leading to multiple roles per object and absolutely no semantics in roles, even though it's theoretically possible).
MAC in itself is vague, there are many many ways to implement it for many systems. In practice, you'll often use a combination of different paradigms. For instance, a UNIX system mostly uses DAC but the root account bypasses DAC privileges. In a corporation, beyond separating your different departments and teams with MAC/RBAC you may allow some DAC for coworkers to share information on your corporate file system.
It'd be better to make your question specific and tell what system(s) you want to protect, if any. What access control to use always depends on the specific situation and context you're considering.
Each system is used for a different overriding security requirement. The three main security requirements are confidentiality, integrity, and availability.
MAC supports a security requirement of confidentiality more so than the others. DAC supports the security requirement of availability more so than the others. RBAC supports the security requirement of integrity more so than the others. there is another...
MAC makes decisions based upon labeling and then permissions. DAC makes decisions based upon permissions only. RBAC makes decisions based upon function/roles.
When the system or implementation makes decisions (if it is programmed correctly) it will enforce the security requirements. If you use the wrong system you can kludge it to do what you want. This happens quite often.
They are not mutually exclusive except for DAC vs MAC. There are combination implementations DAC/RBAC the best example of this Active directory roles and permissions.
RBAC - tends toward databases - a classic example of where you cannot use one of the other systems and must used RBAC is for customer service and billing. When you call the cable company to get your pay-per-view the Customer service representative will say I'm sorry let me transfer you to Billing so that you can pay your overdue bill- they know you have an overdue bill but their role prevents them from taking your credit card information directly. When you get transferred to billing you pay your bill and say can I have my service. They say let me transfer you back- I see you want this service but that's not my function. So both roles can see all the data (no confidentiality) but can only manipulate the fields that they have a particular set of responsibilities for (integrity). -you can argue DAC: but fits the "more so" rule.
MAC - tends toward a military systems or very narrowly defined, high security requirement implementations. 2 that are used quite often TRusted-Solaris and LINUX- MAC kernel module (this used to be SELinux) there're others but you don't care. One of the key elements that only appears in MAC is a construct of dominance. If you have secret level clearance, no amount of permissions is going to get you to see a Top secret document. In commercial entities it is rare that you need this construct. But it brings up the second point that is unique to MAC- if an activity is not specifically allowed then you cannot do it. (this breaks lot of commercial uses primarily because of rapid change to The mission or system requirements) An excellent use of MAC would be on a Web server- where you would write a custom policy (and this is very narrowly defined to that implementation) that states the Core processes can only be executed by the System account. Any processes spawned from that would be required meet specific permissions.
DAC - everybody uses it and the person before me answer well enough.