Why avoid using Apex Trigger and workflow/Process builder together on same object

I’ll try to demonstrate this with a simple example.

Lets say there’s a Stage changed counter field on opportunity object, which is to be updated anytime a stage is on opportunity is changed.

Someone came and wrote a simple workflow rule to manage this, and it was a simple field update to +1 the counter field whenever stage field is changed.

Later another requirement came along —

This requirement was to create a custom child object record to the standard opportunity when counter changed from 4 to 5. This was assigned to a developer who preferred Apex over workflow for obvious reasons.

The after trigger was the written on opportunity object with trigger.new and trigger.old

When they tried to test this with the existing WFR automation, someone came in and updated the opportunity stage to closedwon and set the counter field to 4.

The after trigger didn’t fire because counter was changed from null to 4 and not from 4 to 5,

The WFR did fire because stage was indeed updated, which inturn fired the field update to increment the counter field from 4 to 5.

Now once there is a WFR field update, the before and after update are bound to fire once again.

So this time around the after trigger should fire right? because now the field is updated from 4 to 5, right?!!

No!!! for this after context, the trigger .new value is indeed 5 but the trigger.old value is still null, because —

When a record is updated and subsequently triggers a workflow rule field update, Trigger.old in the last update trigger doesn’t contain the version of the object immediately before the workflow update, but the object before the initial update was made.

And that my reason to not mix automation and trigger separate, what’s yours?