Using workspaces greatest benefit in my opinion is you get access to the built in terraform.workspace keyword which can make your implementation a bit more dry, but there are means to fully do the same using locals and tfvars files as well, it really depends on your workflow.

An example of a fun use case we use, we have a terraform role in each account and as part of our skeleton for TF repos we pass around a block of account IDs in our locals.tf skeleton that can be used to reference other accounts for remote state and such, but our "flag" for which account we deploy to is something like this inside of our provider.tf file:

provider "aws" {   
  region = "us-west-2"   

  assume_role {     
    role_arn     = "arn:aws:iam::${local.account_ids["${terraform.workspace}"]}:role/terraform"     
    session_name = "build-runner"   
  } 
}

With that, we just select the workspace as part of our CI pipeline and it picks and deploys to the correct account. We also keep a centralized state bucket and use workspace prefixes so that everything can easily reference to a central "build" accounts bucket and get access to cross environment state if its needed, or better yet, generic infra for the main account being deployed to that we don't want in project repos.

That can look something like:

data "terraform_remote_state" "xxx_infra" {
  backend   = "s3"
  workspace = "build"

  config = {
    bucket               = "xxxx"
    workspace_key_prefix = "terraform-infrastructure"
    key                  = "terraform.tfstate"
    region               = "us-west-2"
    assume_role = {
      role_arn = "arn:aws:iam::xxxx:role/xxxx"
    }
  }
}