Postman can do that and a lot more as it has a proper scripting runtime. The runtime can be executed outside of Postman too so you are not tied to the GUI want to automate things (with build systems etc.). Chaining as a feature in itself is something we are working on along with speeding up workflows around variables (environments, globals etc.) [Postman founder here]
I guess it's a matter of choice, but we see Paw as a visual tool that makes it easy to setup a request (or a set of requests) to iterate quickly when developing an API or discovering a new one. Because of that, we try to keep actions intuitive and keep scripting as a last resort (JS scripts & extensions are available in Paw too, btw).
I know from experience as an iOS developer (then Python backend guy) that when working on a given project, our mind is already full of business logic. We don't want to add another level of complexity due to the tools we use. And we're writing enough code elsewhere to not want to write code in an app.
As of scripting used for "unit" testing, we have thought about it many time for Paw. And while we will do something somewhat related in the near future, it's a slippery slope. A robust API should have unit tests written with mocks and be part of the server code, not a few assertions made in a 3rd party app. We're quite biased here: many users want this feature, but we don't want to encourage bad practices (as it may be interpreted by some as "ok let's not write proper tests, there's Paw for that").
Anyway, that was to share my point of view as a Paw guy :)
