SOAP and CSV are not sexy. They have plenty of shortcomings. However, those are the formats that are used in the real world today (and for some time to come).
Stream processing is a very useful design pattern but like any design pattern it should be used carefully and only where appropriate (see: Microservices).
If I were to build a new complex ERP from the ground up I'd be remiss not to use something like Kafka or Confluent for data processing.
If I want to communicate with legacy systems though that's an entirely different matter. The same applies when targeting SMBs. You'd have a hard time explaining to small business owners why they suddenly need a newfangled stream processing architecture while their old "Export CSV and load that into Excel" process worked just fine.
I would wager that most data is not of a streaming nature, but as the ability to process live pipelines is relatively new, it gets more attention.
For example, how do you detect when a source's semantics change? This will break any cleansing or transforms done in the stream platform. Until it gets fixed, data may be missing, wrong, or worse (e.g. corrupted) and propagated down stream.
When data is cleansed and transformed early, there is no way to go back to the raw data, unless you carry it forwards too.
Consider these sort of questions for your use case.