It's much more about standardising the approach within a team, and not needing to know your target infrastructure state.
Especially at the stage of a scale up, you'll get a lot of differing views as where to write your scripts - Terraform provides tooling for a specific use case where you don't need to reinvent everything.
At Nimbus[1], we have been trialling using Terraform for template definitions as users are mostly familiar with it, and it allows them to integrate more easily with existing CI/CD processes.
They can easily just add a new Nimbus Workspace to their Terraform and have it spin up a new development environment when their CI requires it.
We recently faced this; if you are using the docker/login action I'd give that a check as it turned out it was logging us out by default at the end of each job; resulting in some race conditions when running multiple runners on the same machine (sharing the same docker daemon).
Simple fix was to add `logout: false` to the action options.
At Nimbus[1], we have been trialling using Terraform for template definitions as users are mostly familiar with it, and it allows them to integrate more easily with existing CI/CD processes. They can easily just add a new Nimbus Workspace to their Terraform and have it spin up a new development environment when their CI requires it.
[1]: https://usenimbus.com - Easy remote development infra for teams