Como acontece com qualquer regra, acho que o importante aqui é considerar o propósito da regra, o espírito, e não ficar atolado em analisar exatamente como a regra foi redigida em algum livro-texto e como aplicar isso a esse caso. Nós não precisamos abordar isso como advogados. O objetivo das regras é nos ajudar a escrever programas melhores. Não é como se o propósito de escrever programas fosse manter as regras.
O propósito da regra de responsabilidade única é tornar os programas mais fáceis de entender e manter, fazendo com que cada função faça uma coisa coerente e independente.
Por exemplo, uma vez eu escrevi uma função que chamei algo como "checkOrderStatus", que determinava se um pedido estava pendente, enviado, devolvido, o que quer que fosse, e retornava um código indicando qual. Em seguida, outro programador apareceu e modificou essa função para atualizar também a quantidade em mãos quando o pedido foi enviado. Isso violou severamente o princípio da responsabilidade única. Outro programador que lê esse código mais tarde verá o nome da função, verá como o valor de retorno foi usado e poderá nunca suspeitar que fez uma atualização do banco de dados. Alguém que precisava obter o status do pedido sem atualizar a quantidade disponível estaria em uma situação difícil: ele deveria escrever uma nova função que duplica a parte do status do pedido? Adicionar um sinalizador para informar se deve fazer a atualização do banco de dados? Etc. (Claro que a resposta certa seria quebrar a função em dois, mas isso pode não ser prático por muitas razões).
Por outro lado, eu não diria o que constitui "duas coisas". Recentemente, escrevi uma função que envia informações do cliente do nosso sistema para o sistema do nosso cliente. Essa função faz alguma reformatação dos dados para atender aos seus requisitos. Por exemplo, temos alguns campos que podem ser nulos em nosso banco de dados, mas eles não permitem nulos, então temos que preencher algum texto fictício, "não especificado" ou eu esqueço as palavras exatas. Indiscutivelmente esta função está fazendo duas coisas: reformatar os dados e enviá-los. Mas eu deliberadamente coloquei isso em uma única função, em vez de "reformatar" e "enviar", porque eu não quero nunca, jamais, enviar sem reformatar. Eu não quero que alguém escreva uma nova chamada e não perceba que ele tem que chamar reformatar e depois enviar.
No seu caso, atualizar o banco de dados e retornar uma imagem do registro escrito parece duas coisas que podem ir juntas logicamente e inevitavelmente. Não conheço os detalhes da sua inscrição, por isso não posso dizer definitivamente se é uma boa ideia ou não, mas parece plausível.
Se você estiver criando um objeto na memória que armazena todos os dados do registro, fazendo as chamadas do banco de dados para escrever isso e retornando o objeto, isso faz muito sentido. Você tem o objeto em suas mãos. Por que não apenas devolvê-lo? Se você não retornou o objeto, como o chamador conseguiria? Ele teria que ler o banco de dados para obter o objeto que você acabou de escrever? Isso parece bastante ineficiente. Como ele encontraria o registro? Você conhece a chave primária? Se alguém declarar que é "legal" para a função write retornar a chave primária para que você possa reler o registro, por que não apenas retornar o registro inteiro para que você não precise fazer isso? Qual a diferença?
Por outro lado, se criar o objeto é um trabalho bastante distinto da gravação do registro do banco de dados, e um chamador pode querer fazer a gravação mas não criar o objeto, então isso pode ser um desperdício. Se um chamador quiser o objeto, mas não escrever, então você deve fornecer outra maneira de obter o objeto, o que poderia significar escrever código redundante.
Mas acho que o cenário 1 é mais provável, então, eu diria, provavelmente sem problemas.