Seu comentário é perfeito.
Quando você olha para um atributo, dificilmente o fará sem um contexto envolvido. E o contexto lhe permite cortar redundâncias. A comunidade Go costuma seguir esses preceitos, doutrinados desde a documentação de sua standard library, e eu acho lindo.

Imagine que você está em um escritório em que todas as portas têm uma pintura com seu nome:

porta sanitários
porta saída de incêndio
porta cozinha
porta sala de reunião

Quando você olha para a porta, está claro que se trata de uma porta. A nomenclatura escolhida se torna redundante, verborrágica e pouco significativa.

O exemplo é bem elementar para deixar claro quão ruim é uma escolha de nomenclaturas verborrágicas e redundantes.

Eu tenho PAVOR de nomes complexos que pouco dizem. Cheguei a trabalhar em empresa cujos nomes dos atributos de banco continham siglas do domínio do negócio, tipo do campo e nome da tabela! Sobrava pouco espaço para dar o maldito nome necessário, pois além, de tudo isso havia limitação de 25 caracteres.

Dar um nome a algo em programação é muito mais do que somente seguir determinados padrões, apesar de ser relevante. É muito mais importante. Dar um nome é tentar dizer algo da forma mais imediata o possível para quem vai ler e usar. Se houver a necessidade de se pensar demais para entender o que significa um nome, todos sofrem desnecessariamente.

Nunca se esqueça: contexto. Leve isso pra tudo em programação. Não somente para nomes de campos em tabelas. Uma variável pode se chamar "a" se estiver dentro de um escopo de função com somente outras 2 ou 3 variáveis. Escopos permitem nomes simples. Variáveis globais ou em escopos muito populosos precisam ser mais descritivas.