Wojciech Jakub Ptak, um desenvolvedor Flex da Noruega com um nome um tanto complicado de se escrever, aproveitou o Adobe Flex Coding Guidelines que escrevi na DClick (que também conta versão em português) e estendeu o documento, acrescentando alguns tópicos interessantes.
Achei fantástica a iniciativa de complementar o documento! Se ele concorda com o que está ali, não há necessidade de criar algo completamente novo simplesmente para chamar de seu. Esse é um modelo, aliás, pelo qual outros documentos e artigos poderiam evoluir naturalmente.
Bem, ainda não li o documento que ele disponibilizou por inteiro, mas ele é basicamente o que está disponível no site da DClick com três tópicos novos: Adobe Cairngorm, E4X Guidelines e Regular Expressions.
Particularmente, embora eu acho interessante ter um "Cairngorm Coding Guidelines", eu não acho que este deva estar dentro de um "Flex Coding Guidelines". Fazendo assim, presume-se que o Cairngorm deve ser utilizado sempre que se utilizar o Flex, e isso não é todo verdade. Aliás, nenhum framework é tão perfeito e abrangente que resolve todos os problemas. Frameworks resolvem problemas específicos, então só os use se você tiver os problemas que ele visa resolver. Ou ainda, como diz o Beck, não se deve achar que um framwork sozinho é a solução, e sim que ele é apenas um ponto de partida.
Nessa linha, há um antigo post do Steven Webster que continua válido: Why I think you shouldn't use Cairngorm. Pensei que já havia publicado esse link auqi no CFGigolô, mas não o achei. De qualquer modo, a leitura é bem interessante, principalmente para os iniciantes em desenvolvimento.
Por favor, não me levem ao extremo: eu acho o Cairngorm fantástico e recomendo a todos os desenvolvedores que dêem uma olhada nele pois ele já se provou muito eficiente e tive ótimas experiências com ele.
Realmente, pelo fato do Documento se chamar "Flex Coding Guidelines", a junção de explicações a respeito do Cairngorm pode dar a impressão que é uma "boa prática" usar esse framework. Isso, conforme você já expôs, não leva o leitor do documento a uma visão real da utilidade de um framework, pois, como você sabiamente disse, o framework tem soluções para problemas específicos. Se você não têm esses problemas em seu projeto, teoricamente poderia desenvolver sema a "ajuda" de um framework.