To simplify, DMARC primarily works by verifying that messages have a DKIM signature that matches their From: domain. There are two modes for this matching. In 'strict DKIM identifier alignment', the From: domain and the DKIM domain must match exactly; if you send with a From: of news.example.com, only a DKIM signature from news.example.com will match (other DKIM signatures may be present but will be ignored by DMARC). In 'relaxed DKIM identifier alignment', which is the default, any DKIM signature from example.com will work; it could still be news.example.com, but it could also be 'example.com' or 'mta-group.example.com'.

The advantage of relaxed alignment is that it makes operation of a central mail sending infrastructure easier (or more generally, mail sending infrastructure that's somewhat detached from the people using it). One group can run outgoing mail, sign everything as 'example.com', and the marketing department doesn't have to bug them for special configuration changes when they want to create 'news.example.com' and start using it (or at least, not as many). If another group sets up special mail-out infrastructure that the marketing department will use, nothing much has to change, since the new group can set up their own DKIM keys and start signing as 'bulk-mta.example.com'. DMARC will be happy all around.

The disadvantage of relaxed alignment is that anyone in your organization who runs their own mail server can send email that passes DMARC for anything in your organization, whether or not they're supposed to use that From: address. Perhaps the marketing department is only supposed to send email as From: news.example.com, but once they have a DKIM key, relaxed alignment will let them send as From: example.com, or support.example.com, or whatever. This also applies to any third party mail sending service that you've delegated DKIM keys to. If marketing has hired MailService to send email as 'newsblast.example.com' and has had you add CNAMEs to MailService's DKIM keys in that subdomain, MailService (or anyone who compromises them) can use those DKIM keys to send DMARC-validated email that is From: example.com itself, or From: 'security.example.com', and so on.

If you have an organization that is either small or quite centralized or both, relaxed alignment may make your job easier, especially if people create (and perhaps remove) a lot of From: domain and host names as projects come and go. The central mail people can just sign everything as 'example.com' and be done with it, without needing to keep track of what has DKIM selectors and what they are and so on. Relaxed alignment also makes it easier to transition from plain DKIM (where the DKIM domain mostly identifies the sending mail server) to DMARC, since all of your mail servers will be using a DKIM domain of <something>.example.com, and all of those pass DMARC for any From: in example.com.

Another way to put it is that relaxed alignment decouples DKIM keys and subdomains from DMARC validation as long as they're all within your organizational domain (such as 'example.com'). Your MTA people can have their own naming scheme for the choice of DKIM signing domains and DKIM keys, and your mail sending users can pick their From: addresses independently of that. You can readily have different outgoing MTAs that people pick between based on various circumstances, possibly including things like geographic or network location.

If you have a large, highly distributed organization with fairly autonomous units, such as a large university, relaxed alignment becomes somewhat alarming. Sub-groups will have their own email sending infrastructure with its own DKIM keys, and if they don't carefully restrict what From: addresses they allow and just sign more or less anything that passes through them, you've just given people with access to 'dept.example.edu' the ability to send DMARC valid email with a From: of 'president@example.edu' or 'chair@deptB.example.edu'. You may not want that. This is the downside of that exact same decoupling of DKIM keys and DMARC validation that we had before,

Some versions of this may not even be malicious, just have undesirable consequences. The publicity group of dept.example.edu may have hired MailService to send out mail blasts that are normally from 'news.dept.example.edu' (and have DKIM keys set up for it), but now they want to send out a special blast using 'dept.office@example.edu'. This will pass DMARC with the DKIM CNAMEs that MailService and the publicity group already have, and if receivers object to it, it may contaminate the reputation of '@example.edu' generally. With strict alignment, you force the publicity group to slow down and talk to someone before they execute this clever idea.

(Whether or not MailService would flag or block this (with relaxed alignment) is an interesting question. After all, your own DMARC policies say that this is okay, and maybe your organizational policies are fine with it.)