Oi Reinaldo,

esta é uma excelente pergunta: confesso que detestei esta mudança no scaffolding, pois preferia o anterior também.

Mas tenho uma sugestão, você pode tentar e depois nos dizer se funcionou.
Faça o seguinte: crie uma aplicação vazia do Grails usando a versão 2.5 ou anterior, que ainda gerava o scaffolding à moda antiga.

Em seguida, nesta nova aplicação, execute o comando "install-templates", que irá instalar os templates de scaffolding padrão na sua aplicação recém-criada.

Na sua nova aplicação, execute o comando install-templates também, e substitua os arquivos GSP pelos que foram gerados na versão anterior. É provável que não funcione de cara, mas pelo menos te dá o caminho para que você possa ir adequando os arquivos de template.

Aproveitei e fiz esta sua mesma pergunta no slack da comunidade Grails internacional, pois também é algo que me incomodou bastante. Vou compartilhar as novidades aqui também.

Oi Reinaldo,

pessoal me mandou uma resposta interessante: basicamente, a gente criar um novo scaffolding baseado no código fonte deste projeto: https://github.com/grails/scaffolding

Boa noite Kiko.

Eu havia tentado a solução que você postou primeiro, gerar o template em uma versão 2.X e substituir o template gerado na versão 3.1.9, que é a que estou usando, do Grails.
Infelizmente não funcionou.
Fiz pesquisas na internet e encontrei a documentação do plugin. Também, encontrei alguns tópicos sobre o assunto em inglês. Tudo que encontrei dá como solução fazer template para o plugin. Fiz alguns testes juntando estas informações e acabou dando certo. Mas gerar os campos um a um, como antigamente ainda não encontrei.
Gostaria de deixar registrado que se você gerar a views e substituir o <f:all pelos campos, na "unha" , funciona. 

Link da documentação do plugin: http://grails3-plugins.github.io/fields/snapshot/ref/Tags/field.html?

Kiko, vou dá uma olhada nesse scaffold que você postou. Vou, também, postar o que fiz (meus testes). Pois, pode servir para outras pessoas.

Pessoal, como eu fiz:
Criei alguns arquivos em locais específicos, funciona tando para views geradas quanto as que rodam em tempo de execução(scaffold).

No index.gsp encontrei: <f:table collection="${clienteList}" /> .  Mantive assim. O que fiz foi um template que vai subscrever o  que o <f:table faz.
Criei dentro da pasta views da aplicação uma pasta chamada "template" e dentro dela criei uma outra chamada "_fields" . Ficou assim a estrutura-> (grails-app\views\templates\_fields).
Dentro de "_fields" criei um arquivo chamado "_table.gsp" . Ficou assim-> (grails-app\views\templates\_fields\_table.gsp).
Conteúdo de _table.gsp:
//------------------------------------------------
<table class="table table-striped table-bordered table-hover table-condensed">
<thead>
<tr>
<g:each in="${domainProperties}" var="p" status="i">
<g:set var="propTitle">${domainClass.propertyName}.${p.name}.label</g:set>
<g:sortableColumn property="${p.name}" title="${message(code: propTitle, default: p.naturalName)}" />
</g:each>
</tr>
</thead>
<tbody>
<g:each in="${collection}" var="bean" status="i">
<tr class="${(i % 2) == 0 ? 'even' : 'odd'}">
<g:each in="${domainProperties}" var="p" status="j">
<g:if test="${j==0}">
<td><g:link method="GET" resource="${bean}"><f:display bean="${bean}" property="${p.name}" displayStyle="${displayStyle?:'table'}" /></g:link></td>
</g:if>
<g:else>
<td><f:display bean="${bean}" property="${p.name}" displayStyle="${displayStyle?:'table'}" /></td>
</g:else>
</g:each>
</tr>
</g:each>
</tbody>
</table>
//-------------------------------------
Funcionou beleza comigo.

Dentro da mesma pasta , "_fields",  criei um arquivo chamado "_list.gsp" . Ficou assim-> (grails-app\views\templates\_fields\_list.gsp).
Conteúdo de _list.gsp:
//------------------------------------------------
<ol class="property-list ${domainClass.propertyName}">
<g:each in="${domainClass.persistentProperties}" var="p">
<li class="fieldcontain">
<span id="${p.name}-labelX" class="property-label"><g:message code="${domainClass.propertyName}.${p.name}.label" default="${p.naturalName}" /></span>
<div class="property-value" aria-labelledby="${p.name}-label">${body(p)}</div>
</li>
</g:each>
</ol>
//------------------------------------------------
Desta forma subscreve-se  o <f:display bean="cliente" /> em show.gsp, por exemplo.

Para os forms de create.gsp e edit.gsp o templete fica em outro lugar. Vamos lá.
Dentro da pasta views da minha aplicação criei uma pasta chamada "_fields". Dentro de _fields é possível separar o template para cada classe, criando pastas com o nome da classe desejada assim cada entidade possuir um comportamento diferente do padrão. Mas eu fiz de uma forma que um único arquivo sirva para toda aplicação. Dentro da pasta "_fields", ao invés de criar uma pasta com o nome de uma entidade, criei uma chamada "default". Ficou assim-> grails-app\views\_fields\default. Dentro dela criei dois arquivos: _widget.gsp e _wrapper.gsp ( Veja a documentação nesse link: http://grails3-plugins.github.io/fields/snapshot/guide/customizingFieldRendering.html ).

_widget.gsp
//-----------------------------------------

<g:textField name="${property}" value="${value}" class="form-control" id="${property}"/>
//----------------------------------------

_wrapper.gsp
//---------------------------------------

<div class="form-group ${invalid ? 'error' : ''}">
<label for="${property}">${required ? "$label *" : label}</label>

<%= widget %>

<g:render template="/_fields/errors"/>

</div>
//---------------------------------------

Em _wrapper.gsp tem uma linha renderizando um template  "_error" esta linha pode ser apagada, mas se quiser deixar como está...
O "_erros.gsp" está na pasta "_fields" . -->  grails-app\views\_fields\_errors.gsp

 _errors.gsp
//---------------------------------------
<g:if test="${invalid}">
<ul class="error">
<g:each in="${errors}" var="error">
<li>${error}</li>
</g:each>
</ul>
</g:if>
//---------------------------------------
?
Espero que ajude alguém, ou que, pelo menos, dê uma luz. O que postei não é uma solução definitiva. Ainda não olhei o link que o Kiko postou. 
Vou continuar minha busca por uma solução bacana. Na verdade, preferia a forma antiga que o Grails gerava o código.
Abraços a todos.

Também fiquei bastante incomodado com a mudança do Grails 3.X passando a utilizar o Fields Plugin. Apesar dele possuir todo um mecanismo de customização dos templates, deste o tipo de dados de saída (Ex: String), como da classe de domínio que está sendo "renderizada" (Ex: com.acme.Cliente), entendo que o modelo anterior permitia uma maior manutenabilidade e flexibilidade na construção das páginas, sem perder a agilidade no desenvolvimento.

Em meus projetos pessoais, ainda prefiro utilizar o procedimento sugerido pelo Kiko. Instalando os templates de scaffolding do Grails através do comando install-templates e depois customizando-os com os templates tradicionais sem o uso do Fields Plugin. 

Boa tarde Guilherme Andrade. Detestei este plugin ( Fields ) . Você teria como me ajudar, passando a parte do código do seu template customizado onde os campos não usam o Fields Plugin ?
Já pensei em até regredir o projeto para o Grails 2.5 . Mas não é isso que eu quero.   
Abs.

Reinaldo, obrigado pela explicação. Me ajudou abeça, no início fiquei um pouco incomodado com a mudança, mas depois da sua explicação achei bem bacana e acho que já me acostumei. 

Leonardo, eu também odiei este plugin, para quem customiza os Templates ele torna a tarefa mais lenta.

Realmente, agora usando um pouco mais é bem ruim mesmo. Estou desenvolvendo um teste aqui e estou fazendo um 'work-around'zinho heheh .Eu customizei o F:all como o Reinando ensinou, depois eu copio e colo o o html do navegador e uso o _form com o G:render. =/ 

Ainda bem que não estou sozinho!
Sei que traz uma certa limpeza no código o uso desse plugin, mas na prática mais atrapalha do que ajuda quando se precisa personalizar e reorganizar os campos dos formulários.
Primeira vez usando o Grails 3.X... ainda estou me acostumando com as novidades.

O scaffold agora é baseado no plugin Fields, e isso é muito bom. O único problema dele é que é um pouco mau documentado.
Você pode personalizar os templates que ele utiliza para o widget (caixa de texto, combo, etc), para o valor textual (utilizado para exibição apenas), e para o container (widget + nome do campo), a nível de action, a nivel de controller, pelo tipo da propriedade ou pelo nome da propriedade .

Como é dito na documentação: O uso deste plugin dentro do scaffold permitiu aumentar enormemente a vida util do scaffold dentro do projeto

No meu projeto personalizei os layouts do scaffold para atender ao meu layout e criei mais alguns templates para o Fields para atender a tal layout.
Se eu precisar personalizar algum campo, eu consigo ir muito mais longe sem abrir mão da view dinamica

"pessoal me mandou uma resposta interessante: basicamente, a gente criar um novo scaffolding baseado no código fonte deste projeto: https://github.com/grails/scaffolding"
Não acho que precise criar todo um novo plugin, apenas os templates que renderizem os campos do jeito que vcs preferem.
Infelizmente, com a versão atual do scaffolding (o que vem no grails por padrão), apenas o projeto principal (a aplicação em si) pode fornecer templates para scaffold, um outro plugin não conseguiria, então não daria para fornecer estes templates na forma de plugin. Porém eu tenho uma implementação para este issue https://github.com/grails3-plugins/scaffolding/issues/1 que resolveria esta questão, se os devs me dessem um OK poderia submeter o código.

Obrigado, Magno. Nos mantenha informado se os desenvolvedores incluírem seu código no projeto.
Eu usei mais um pouco e estou percebendo as vantagens que o plugin trouxe ao scaffold e ao grails. Ainda estou apanhando um pouco com a personalização dos layouts, mas daqui a pouco fica tudo bem. 
Para fazer uma formulário em cascata (tipo UF/Cidade) você acha que a personalização do JS/remoteFunction deve ficar dentro do arquivo template?

Vc tá falando de ter um formulario para criar/editar cidade, que possui um campo para selecionar o estado?
Vc criaria um template para o tipo "estado" que renderiza um select

Ou cria um template para a associação "oneToOne" que faça isso dinamicamente para qualquer tipo

Se for algo mais complexo que isso, como um master detail, aí já nem uso scaffold

Fala pessoal, vim de outro post com a mesma dúvida que pelo jeito já foi amplamente debatido aqui. Como outros, ainda não me acostumei com a mudança brusca também, inclusive também pensando em regredir o projeto, conforme o Reinaldo falou e, assim como ele, também não quero ter que fazer isso.

- Alguém trabalha com GRails tendo uma equipe de Frontend pra customizar os layouts e já mostrou esse plugin pra eles? Se sim, a aceitação foi boa? A curva de aprendizado foi ok? - Precisaram fazer ajustes finos a nível de layout/ajax usando os templates dos campos?
- Alguém já deu rollback no uso do plugin? Se sim, por que?

Outra coisa, achei muita coisa pra fazer pouco, todavia no longo prazo pode ajudar bastante. Enfim, vamos conversando por aqui, achei a documentação do plugin bem OK, tá faltando mesmo me acostumar eu acho, assim como algumas outras mudanças... ;)

Abraços a todos.

O que vcs acharam tão problematico assim a ponto de se falar até em regredir a versão do Grails?

Lembrando apenas os templates padrão do scaffold utilizam o plugin fields, nada impede de se criar novos templates utilizando outras estrategias

Vamos a um exemplo, se eu quero que todos os campos bigdecimal sejam renderizados como um input type="number" basta eu criar um arquivo em grails-app/views/_fields/bigDecimal/_widget.gsp com o conteúdo:
<input type="number" name="${propertyName}" value="${bean?.get(propertyName)}"/>

Como isso seria feito anteriormente? Não tive muita experiencia com scaffolding no grails 2.x

"Como outros, ainda não me acostumei com a mudança brusca também..." como falado no trecho, é apenas costume mesmo e talvez tempo pra deixar a App funcionando, que talvez não possa esperar a curva de aprendizado de mais um plugin.

No mais, é isso, parece ser fácil de fazer (só fica dependendo mesmo do costume) e me pareceu bem documentado.

Abraços ;)

No meu primeiro contato eu achei o plugin bem chato, pois mudou a maneira com que eu estava "acostumado" a me organizar e ser mais produtivo. Hoje eu já vejo muitos pontos positivos e a forma que ele lida com os templates baseados nos diretórios é uma mão na roda. O que o magno comentou há alguns posts é verdade. A documentação podia ser um pouco melhor, mas já ajuda bastante.
Para formulários em ajax eu não estou usando o fields... também não consegui usar a tag f:table para trazer uma o detalhe de uma propriedade ... tipo:
<f:table collection="anyInstanceList" properties="['id','name','attribute.name', 'attribute.id']"/>
Mas ainda estou me adaptando

A bem da verdade, o scaffolding do Grails 3 foi feito meio nas coxas. Fui acessar o github do plugin para sugerir uma funcionalidade que eu precisava, e depois baixei o codigo para implementar esta funcionalidade pois já havia uma issue com uma solicitação que me atenderia, o que pude observar é que o projeto não tem nenhum teste, a ultima alteração nos fontes foi há 6 meses e há diversas issues em aberto que não receberam nenhum tipo de feedback (nem mesmo para rejeita-las).
Quando o Grails 3 foi lançado sequer havia scaffolding, pois aparentemente foi julgado desnecessario