Example: You receive a timestamp of an event in Paris: 2024-03-31 01:00:00+01:00. If you allow addition, you may be tempted to think you can "just add three hours" and get 04:00:00+01:00. However, because Paris has a DST transition, you'd actually want to have 05:00:00+02:00
In the end, the choice is between "users know what they're doing, just let them" and "users need to be prevented from making common mistakes". I choose the latter.
Note that also NodaTime doesn't support arithmetic on their OffsetDateTime, for the same reason.
When I see the example my thinking is: Well, if you want a time offset relative to Europe/Paris then define your time zone that way instead. Of course I haven't seen other libraries give that option and maybe for good reasons.
Since you know the offset then adding three hours should be unambiguous no? Convert to UTC, add three hours, convert back to target timezone, which would net you the correct 05:00:00+02:00.
What if you don't even know the target offset?
You may happen to know it for an event three hours in the future, but what if you're adding three months? With that time frame, the relevant laws even may not have been passed yet.