For me, the compelling part was at my last company, we'd build these complicated distributed systems with a whole lot moving pieces—any of which could go down at a moment's notice. For a complex enough system, there was sometimes more work to be done to deal with any part of the system failing than to build the system itself. Basically, we were implementing our own bespoke version of Temporal over and over again.
To your point, the complexity of a SQL/PHP application is significantly smaller, but, the value proposition of Temporal is probably still there: If any part of the checkout process fails (e.g. charging the credit card, successfully triggering the order after they've charged the credit card, timing an email if there is an abandoned cart, handling the moving pieces of a return). These pieces are either handled manually by a human or you've got a decent amount of business logic in place to handle each of these edge cases individually.
The value-add of Temporal—in this case—would be that it would keep track of where the customer/order was in the overall flow of ordering something and pick up where it left off in the event that something went wrong.
To your point, the complexity of a SQL/PHP application is significantly smaller, but, the value proposition of Temporal is probably still there: If any part of the checkout process fails (e.g. charging the credit card, successfully triggering the order after they've charged the credit card, timing an email if there is an abandoned cart, handling the moving pieces of a return). These pieces are either handled manually by a human or you've got a decent amount of business logic in place to handle each of these edge cases individually.
The value-add of Temporal—in this case—would be that it would keep track of where the customer/order was in the overall flow of ordering something and pick up where it left off in the event that something went wrong.