You're right that FIM assumes the possibility of compromise, but that's exactly the point - it's a detection control, not a prevention control. Prevention (read-only mounts, immutable bits, restrictive permissions, etc.) is necessary but not sufficient. In practice, attackers often find ways around those measures - for example, through misconfigured deployments, command injection, supply chain attacks, or overly broad privileges.

File Integrity Monitoring gives you a way to prove whether critical code or configuration has been changed after deployment. That’s valuable not only for security investigations but also for compliance.

For example, PCI DSS (Payment Card Industry Data Security Standard) explicitly requires this. Requirement 11.5.2 states:

"Deploy a change-detection mechanism (for example, file-integrity monitoring tools) to alert personnel to unauthorized modification of critical content files, configuration files, or system binaries."

Sure, a "sufficiently advanced" attacker could try to tamper with the monitoring tool, but (1) defense in depth is about making that harder, and (2) good implementations isolate the baseline and reports (e.g. write-only to S3, read-only on app servers), which raises the bar considerably.