"I want to be clear here, I am not advocating writing “proper” scripts, just capturing your interactive, ad-hoc command to a persistent file."
What's the difference? Why not version control it, share it with colleagues. Imagine writing a unit test to test a new feature then deleting it when done, what a waste. Ok it's not exactly the same because you aren't using these scripts to catch regressions, but all of that useful learning and context can be reused.
I don't think the language you use for scripting is too important as long as the runtime is pinned and easily available on all engineers machines, perhaps using a toolchain manager like... mise[3].
[1] https://mise.jdx.dev/tasks/ [2] https://mise.jdx.dev/shell-aliases.html [3] https://mise.jdx.dev/dev-tools/
Because I'm hardcoding directory paths.
Because I'm assuming things are set up a particular way: the way they are on my machine.
Because this is hardcoded to a particular workflow that I'm using here and now, and that's it.
Because I do not want to be responsible for it after no longer needing it.
Because I don't want to justify it.
Because I'm hard-coding things that shouldn't be checked in.
Because I don't want to be responsible for establishing the way we do things based on this script.
Given the choice between starting with an almost-working script or starting from scratch, I’ll take the former, it might save a few hours.
My colleagues and I don’t do this 100% of the time, but I never regret it and always appreciate it when others do.