I see. If these events are sporadic and MOT always eventually add Arabic names, it may be not worth any trouble at all!
But knowing this, I think the following is absolutely the right approach: If MOT’s new value for ar/en is null, you should pretend that MOT didn’t update the value at all. Essentially, this keeps the stale name:ar just as it keeps the stale name. This keeps to the convention at the cost of a tiny code change.
Basically, name:ar and name should always be in sync if the name is Arabic. If you decide to remove one, you should remove the other, and if you keep one, you should keep the other.
For the record, the name conventions have been a consensus for a long time. If name is he, it should be also in name:he, if name is ar, it should also be in name:ar. Israel is very multilingual and sometimes the name language varies literally in adjacent shops. You can’t even determine the local language by a place polygon. So this makes it very simple to parse. Want hebrew? go name:he. Want arabic? go name:ar. Want local language? Go name.
The point is, when two bots disagree on a principle, and one bot is doing something that is considered a mapping error for the other, issues may rise depending on future implementations. Besides, there would be changeset noise even today. (Another bot would always copy name to name:ar after your bot removes it)
I’m afraid I don’t have much skin in this game, but, if these links break, -and they will break-, then you’d have dead weight for all of eternity; generations upon generations of mappers would waste a few brain cycles parsing a dead link, a few seconds waiting for a dead link to load, and a few joules of electricity. OSM servers would forever store and transmit needless data, emitting more CO2, accelerating the extinction of mankind 
And if codeberg.org gets owned by an evil madman in a decade (god forbid), then you’d have no way to divert innocents away from an evil link.