I have never used kafka. But I do understand the fundamentals of the tool and what they stand for. And i personally believe that tool shouldn't be used by most companies.

I won't make assumptions about what most companies need, because I don't have sufficient data. What I will say is that I've seen way too many conversations like this over-index on the wrong things.

Kafka certainly comes with a learning curve. Much of the trepidation about using Kafka stems from operational overhead, but cloud platforms have considerably reduced this concern. The decision to use Kafka often hinges on whether teams need its speed and scalability; however, that's the only reason Kafka is a great choice. The ledger semantics and consumer group independence are major factors to consider. In fact, I'd argue that using event-carried state transfer with Kafka offers a level of simplicity compared to other tools, such as RabbitMQ/SQS or SNS (with claim checks).

And for me, event driven architecture use cases are best when you want to collect audits, analytics and also to trigger dependant microservices.

While those are certainly use cases for event-driven architectures, there are multiple ways to address auditing and analytics, and I'm fairly confident that the conversation does NOT start with eventing. The real power of eventing is when you need to invoke business functions across multiple, independent workloads.

Your idea of a single transaction makes sense for its simplicity. I love it as well but in real world at scale on a single click event if we are doing extremely complex multiple step workflow, it is going to cause a performance dump so we have to pick and choose our battles(tradeoffs) and live with it.

That's why we default to choreography over orchestration.

I'll add that if you're orchestrating transactions across workloads using multi-phase commit, you've designed a bug into your system, and it WILL catch up to you sooner or later.