This rule applies to both directions of a flow. Under 11.5, BIG-IP retains its full-proxy "client-server" view for Diameter traffic. In this architecture, the "client-side" is a transport flow between a system and a BIG-IP Virtual Server. The "server-side" is the proxied flow based on client-side traffic. Thus, when a Diameter instance initiates a flow toward a BIG-IP Virtual Server with the diameter profile applied, this usually initiates a server-side flow toward a pool member, which is a different Diameter instance. I say "usually" because it may re-use an existing server-side Diameter connection. In either case, there client-side traffic and server-side traffic belong to single connection (aka, flow) table entry. the DIAMETER_EGRESS event will fire just before a Diameter message is proxied in either direction.
So let us assume your flow looks like this:
peer1 <--> BIG-IP <--> peer2
peer1 is talking to a BIG-IP Virtual Server, while peer2 is a pool member. Let's say that peer1 sends a CCR with the Origin-Realm set to "ims.mnc090.mcc100.3gppnetwork.org". The iRule above, if applied to the Virtual Server, will fire. The message will be proxied to peer2, but the Origin-Realm will be set to "ims.mnc099.mcc100.3gppnetwork.org". When peer2 responds with a CCA, it belongs to the same BIG-IP connection table (aka, flow) entry, so the iRule will apply to it, as well. Therefore, when it assert "ims.mnc099.mcc100.3gppnetwork.org" as the Origin-Realm, the message will be proxied to peer1, but the Origin-Realm will be changed to "ims.mnc090.mcc100.3gppnetwork.org".
Based on your request, I believe this is what you desire and expect.
If, on the other hand, you are saying that either peer1 or peer2 may initiate a Diameter connection (meaning, it will initiate the transport and assert the CER), then you will need a Virtual Server or set of Virtual Servers (each with the diameter profile and this iRule applied) to which either peer can connect.