O método PATCH poderia ser aplicado, se por exemplo, eu tivesse uma rota exclusiva só para alterar a imagem
Na verdade, não!
Se você tivesse uma rota exclusiva para alterar somente a imagem, não seria necessário utilizar o método PATCH! Se fizer uma rota separada, a imagem seria considerada uma entidade separada, e não um campo da entidade produto. Então poderia ser um PUT mesmo. Ter uma rota separada para a imagem pode ser uma boa solução também (talvez até a melhor), como já sugeriram, mas o PATCH não é necessário nesse caso, pois você estaria alterando a entidade inteira, e não um pedaço dela.
Talvez o meu resumo tenha sido resumido demais...
O PUT é utilizado quando estamos substituindo a entidade existente por completo (e se entidade não existir, ela é criada). É como se a antiga deixasse de existir, e outra ficasse no lugar dela, com o mesmo ID.
E o PATCH é utilizado quando queremos atualizar valores daquela entidade existente. Pode ser um ou todos os valores. Ainda é a mesma entidade, parecida, terá o mesmo ID, mas será diferente.
Se modificamos todos os valores da entidade, o resultado do PUT e do PATCH é o mesmo. mas se modificamos somente alguns valores, o resultado é diferente!
A ideia é a seguinte: de qualquer forma o frontend tem que passar os valores novos dos campos editados para o backend através do request body, né? Segundo o padrão REST, se você utiliza o PUT, o seu frontend seria obrigado a passar todos os valores, de todos os campos da entidade através do request body - independente se todos eles mudaram ou não. Ou seja, nome, preço, quantidade, imagem, tudo. Se você não passa algum desses valores, o padrão REST indica que as colunas em branco sejam atualizadas para nulo no banco de dados! Ou seja, tudo que não é passado é jogado fora! No banco, você altera a linha inteira de uma vez.
Com o PATCH, o frontend só envia os campos que foram alterados (e seus novos valores). No seu controller você itera sobre cada campo recebido no request body, e atualiza somente as colunas correspondentes no banco de dados. Se o cliente muda só o nome e o preço, o cliente faz uma requisição enviando somente o nome e o preço no JSON do request body, através de um método PATCH, e o backend deve atualizar somente esses valores no banco de dados - os valores não enviados continuam iguais já estavam no banco, ao invés de ficar nulo. Também é possível alterar todos os campos através do PATCH, desde que cada um deles tenha sido alterado pelo usuário.
E lembre-se de que você não precisa escolher entre criar um PUT ou um PATCH. Você pode criar as duas rotas. Na verdade, é até encorajado, já que em determinados momentos pode fazer sentido chamar um ou outro. Um sistema CRUD é baseado em Create (POST), Read (GET), Update (PUT e PATCH), e Delete (DELETE). Não faz sentido criar um POST e não poder criar um DELETE também, né?
Aliás, é incomum um usuário ter, por exemplo, um produto com nome maçã, uma foto de maçã, e preço de maçã, e depois ele querer atualizar esse produto para banana, preço de banana, e foto de banana. É mais comum que ele delete a maçã (DELETE) e crie uma banana do zero (POST) né? Mas se ele quiser fazer isso, ele pode fazer tranquilamente utilizando o PATCH também.
De qualquer forma, no seu caso específico, mantenho a recomendação de utilizar o PATCH no lugar do PUT, e enviar na requisição somente os pares de campo-valor que mudaram, para seguir o padrão RESTful.
Recomendo também estas duas leituras breves, para exemplificar e complementar: https://medium.com/xp-inc/node-js-atualiza%C3%A7%C3%B5es-parciais-com-o-verbo-patch-61b47542fbaa
https://stackoverflow.com/questions/28459418/use-of-put-vs-patch-methods-in-rest-api-real-life-scenarios