It's call "event sourcing", and it is occasionally useful. The main upside is that in most cases, it moves responsibility and cost to the consumer.

I've had to implement something like that in the past, when I had to interface to self-hosted JIRA instance - we had API access, but it was pretty slow, and any sort of complex queries would bring server to knees. I've ended up making a process which constantly syncs JIRA changes to our internal database, and then we could query our DB as much as we wanted.

So you probably want to find out what was motivation for the rule. And I am pretty sure it would be some sort of corporate dysfunction:

Maybe app2 is rarely-used, so it is running on cheap servers - while app1 will have significantly more hits. And app1 developers decided to be lazy and make 20 API calls to app2 for each page load. And in the past, this caused app2 to go down, which caused a whole bunch of shouting and finger-pointing, so management said: "ENOUGH! Everything goes through the event bus"

Maybe app2 maintainers cannot be trusted to keep servers up, and have accidentally destroyed their own servers, twice, causing company-wide outage in mission-critical app1. So management does not want a repeat of that.

Maybe IT department forces everyone onto in-house VM orchestrator, and it loves doing day-long maintenance/upgrade events on random servers. This caused extreme outages in the past, so management forced everyone to break dependency.

Maybe the corporate security director read in the trade magazine that open ports are bad, and decided that they do not trust any random developer to listen even on the internal network, only the blessed application - the event bus - can be trusted to listen for connections. (Of course you can get compromised via event bus message, but that director is too clueless to realize this)

Maybe a Super Principal Developer Plus wrote / set up that event bus themselves, and they have enough influence to force it on everyone...

I can keep guessing and guessing, so the first thing to do is to figure out why this rule was made, and what is the motivation for it. This will let you know of the best strategy to fight it.

I'm familiar with event sourcing. From what I understand, it's useful within bounded context/domain/app. I.e., from the outside you'd never know an app is event sourced (it's an implementation detail). Event sourcing is fantastic.

My concern is with cross-app event sourcing: N copies of data/events across N apps. Greg Young strongly advises against this in this video: https://www.youtube.com/watch?v=LDW0QWie21s

I have no idea how this came about. I think it's mainly driven by one engineer. I don't think it's related to any issues related to APIs in the past, in fact I'm not sure they've ever had APIs. There are numerous issues that have come up due to the nature of this system.

These are mostly internal apps not used by that many people. Scale isn't an issue.

I'm advocating for Events + API. With the idea that if you get an event that says "Widget 123 updated", you're free to hit the API to get whatever data you need.