Four conditions. Any one of them justifies the platform; none of them applying means the honest answer is to say so.
ONE: THREE OR MORE SYSTEMS IN ONE BUSINESS TRANSACTION. Not three systems in the estate — three that must be coordinated in one flow, where a failure halfway needs a defined outcome. Point-to-point can chain calls; it cannot hold the state of a half-finished sequence.
TWO: TRANSFORMATION BEYOND A FIELD MAPPING. Enrichment from a third source, aggregation across records, conditional routing by content, a format nobody's adapter produces. A field-to-field mapping belongs in the interface; logic hidden inside an extract query is logic nobody can find later.
THREE: STATEFUL ERROR HANDLING. Retries with backoff, a queue somebody works from, resubmission after correction, a view of what is in flight. You can build each of these by hand; a platform is where they already exist, and the question is whether you are building an integration or an integration platform.
FOUR: A SCHEDULE WITH DEPENDENCIES. Several flows that must run in order, where a failure in one stops the others.
IF NONE APPLIES, SAY SO. That sentence is the deliverable of this module, and it is worth more to a client than a build: "this is a nightly file and Fusion does it natively; here is what OIC would add and here is what it would cost" is advice. Building it anyway is a sale.
And name WHICH condition applies when you do recommend it — that is the sentence that survives into the design document and answers the question somebody asks a year later.