CSP violations (such as XSS vulnerabilities) can manifest themselves on non-public pages, where they'd be difficult to detect with a crawler.
In addition, the Web Reporting API covers more than just CSP. It can also report various types of certificate errors, such as those triggered by violations of the Expect-CT and Expect-Staple headers (such violations might occur if your users are under attack by a MITM).
I'm not certain what the implementation status is in various browsers, but the relevant RFCs (e.g. for HPKP) typically recommend that user agents retry the submission of reports. The report URIs themselves may also use HPKP to prevent them from being intercepted (as opposed to just DoSing the submission). There are certainly scenarios where an attacker can only temporarily MitM the victim and the reporting mechanism would still be of use eventually. The reporting itself is not the enforcing mechanism, so timely submission is not the most important thing in the event of an attack.
That said, it's true that the biggest practical use people get out of report-uri is to test the roll-out of these headers and to detect issues they might cause.
In addition, the Web Reporting API covers more than just CSP. It can also report various types of certificate errors, such as those triggered by violations of the Expect-CT and Expect-Staple headers (such violations might occur if your users are under attack by a MITM).