To confirm it is this and not your cluster, before you upgrade anything:
Time one wait against reality. While the job is sitting on the wait, run a kubectl get for that object in another terminal. If it is already gone and Helm is still waiting, the cluster has done its part and the client is the problem. That single observation separates "Kubernetes is slow to delete" from "Helm is slow to notice", and they have completely different fixes.
Check the arithmetic. Count your before-hook-creation hooks and multiply by your --timeout. If that lands near the extra time you are seeing, you have your answer without changing anything. It also predicts what happens next: raise the timeout to be safe about something unrelated and your deploys get slower in exact proportion, which is a genuinely confusing thing to debug from first principles.
Run with debug logging on one upgrade and look at what the waiter says. The lines about waiting for resources to be deleted carry timings, and the gap between the last useful line and the resumption is the whole story.
One caution on the rollback if you go that way: pin it properly in whatever installs Helm in CI. A rollback that lives in one engineer's shell is a rollback that quietly ends the next time the runner image is rebuilt, and then you are debugging this again in three weeks with no memory of having solved it.