Perfect for projects where infrastructure is logically separated (separate AWS accounts)
Good when there is no is need to modify resources shared between AWS accounts (one environment = one AWS account = one state file)
Good when there is no need for the orchestration of changes between the environments
Good when infrastructure resources are different per environment on purpose and can't be generalized (eg, some resources are absent in one environment or in some regions)
As the project grows, it will be harder to keep these environments up-to-date with each other. Consider using infrastructure modules (off-the-shelf or internal) for repeatable tasks.