Se eu não estou preocupado com o teste de unidade e com a troca de meu acesso a dados posteriormente, usaria meus objetos de estrutura de entidades como meus objetos de negócios, tudo bem?
Eu tenho um banco de dados existente para o qual eu gerou entidades e um datacontext, e tenho classes parciais para manter meus métodos e quaisquer propriedades adicionais (não de banco de dados). Eu li bastante sobre padrão de repositório e outras formas aparentemente complexas de configurar isso, mas não tenho certeza de que tudo isso é necessário. É um aplicativo .NET Web Forms que usa o Entity Framework 6.1.3 e não terá testes de unidade.
Existem outras razões pelas quais devo evitar uma abordagem tão simplista?
Eu não acho que você deva usá-los como objetos de negócios. De acordo com Vaughn Vernon EF é inflexível demais para ser usado diretamente como objetos de negócios
Em vez disso, use-os como objetos de estado. Isso é envolvê-los com um melhor encapsulamento de sua lógica de negócios. No link que eu forneci ele estava falando sobre DDD. O que você chama de objetos de negócios é chamado de raízes agregadas no DDD, mas o ponto ainda permanece.
Eu não estenderia os POCOs para usá-los como objetos de negócios. Ele irá misturar lógica de domínio com lógica de dados e os códigos se tornarão muito difíceis de manter no futuro.
Mas você também mencionou que não terá testes unitários. Então, talvez você esteja construindo um projeto único, de curta duração, que não precisa ser mantido e, então, pode estar certo. Apenas lembre-se que ele pode criar muitas dívidas técnicas com as quais você (ou outros desenvolvedores) tem que lidar mais tarde.