Oi Marcelo, tudo bom?
1) a view se encontra no CLIENTE separada do do model e do controller no SERVIDOR.
Na verdade, isso depende de como a aplicação foi arquitetada.
Se você tem um sistema MVC com a camada de view interna ao framework, normalmente um template engine (Blade do Laravel, Twig do Symfony, Razor do Asp .NET, etc) a renderização da view fica na camada do servidor. O que fica no client é apenas o html/js renderizado.
Se você tem um sistema MVC com a camada de view em outro serviço. Ou seja, se você tem uma API que entrega dados a uma aplicação qualquer Node, React, Vue, ou até mesmo outra aplicação PHP a view se encontra no cliente.
2) no modelo original, a view ficava observando o modelo e, quando o mesmo mudava, automaticamente informava a view. Até onde vi, não conheci framework PHP algum em que o modelo informasse automaticamente a view sobre as mudanças -- quem o faz seria o controller -- assim como no Smalltalk.
Neste sentido, ainda faz sentido falar em "MVC" no contexto web ?
É ai que ta a sacada. Isolar a arquitetura do sistema em Views, Models e Controllers não necessariamente implica em implementar isso em um modelo reativo (como o smalltalk aparenta ser).
As aplicações mvc Web, não só em PHP, tem como objetivo facilitar as requisições HTTP e isolar um sistema de rotas suficiente para que você consiga associar uma URL a um bloco de código sem se preocupar em acessar a requisição pura e caçar a informação lá dentro.
A proposta do MVC em um contexto reativo também é valida. Você pode, por exemplo, montar um sistema MVC no front-end de uma aplicação em Node/React para isolar os comportamentos em arquivos java script.
Ou seja, o padrão arquitetural não engessa o escopo da implementação torando a coisa mais dinâmica e adaptável a necessidade (que sempre muda ao longo do tempo) =)
Abraço!
