In my opinion, naming the default branch "prod" (or some variation) is actually a fantastic idea almost regardless of workflow. Here's why:
In every workflow, there's a branch, somewhere, that pushes to production. Whether that's the default or not and what exactly it's named isn't particularly relevant in the context of git (branches can always be changed). It's still the one that gets pushed to the production server or pulled by the pipeline to build the production result in some fashion. This makes it explicitly clear that this branch is the production one.
Naming the default branch "prod" sets up that expectation and discourages directly changing the code on that branch from the get-go (something I know I'm guilty of). In other words, it forces us to be mindful of what we're doing, even early in the project, where habits are most likely to be formed and ingrained, but workflows and processes are most likely to be super loose. We start with the habits we want in the long run, instead of allowing bad habits and then having to unlearn them later.
In workflows where the default branch isn't supposed to be "prod," it forces that split immediately (again, avoiding the fast-and-loose tendency that can happen early in a project), by forcing a new branch to be created to become the new default branch.
The beauty, too, is that most of this can be automated with aliases if you want the automation. Then you get the git scaffolding your project needs from the beginning, and you've still gone through the process of making thoughtful decisions about it (or, you made the deliberate effort to not be thoughtful and mindful about how you set up your git repository).
In my opinion, naming the default branch "prod" (or some variation) is actually a fantastic idea almost regardless of workflow. Here's why:
In every workflow, there's a branch, somewhere, that pushes to production. Whether that's the default or not and what exactly it's named isn't particularly relevant in the context of git (branches can always be changed). It's still the one that gets pushed to the production server or pulled by the pipeline to build the production result in some fashion. This makes it explicitly clear that this branch is the production one.
Naming the default branch "prod" sets up that expectation and discourages directly changing the code on that branch from the get-go (something I know I'm guilty of). In other words, it forces us to be mindful of what we're doing, even early in the project, where habits are most likely to be formed and ingrained, but workflows and processes are most likely to be super loose. We start with the habits we want in the long run, instead of allowing bad habits and then having to unlearn them later.
In workflows where the default branch isn't supposed to be "prod," it forces that split immediately (again, avoiding the fast-and-loose tendency that can happen early in a project), by forcing a new branch to be created to become the new default branch.
The beauty, too, is that most of this can be automated with aliases if you want the automation. Then you get the git scaffolding your project needs from the beginning, and you've still gone through the process of making thoughtful decisions about it (or, you made the deliberate effort to not be thoughtful and mindful about how you set up your git repository).
I could not agree with you more!