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.