After save is not a good event for business logic. The purpose of this was intended for events like writing to a queue for integrations. Something where most of the processing has already occurred but you have slight processing to do on top of it.
After save is when a transaction has been started but not committed on the database. This can lead to database blocking while your script is running. I've seen automation scripts in customer environments that ran for minutes which is a very long time to have blocking on the database.
And if you modify the same record (or Maximo logic modifies that record for some reason), you can easily create infinite loops. This is because you can no longer modify the record in memory. That record has been saved but not committed to the database already, so another save on the record is not possible. Thus you get a new set (typically using MXServer.getMXServer().getMboSet()) and trigger a save, which causes all of your automation scripts to fire again. It's also important to emphasize that the new set is typically a new transaction that is committed independently of the original transaction. That means you can run into situations where part of your updates are committed to the database and others are rolled back which is a terrible state to be in.
There are legitimate scenarios where after save/after commit events make sense which is why they exist. But very rarely are they used correctly.