그건 View와 Presenter 의 인터페이스를 MovieSearchContract라는 네임스페이스에 안에 두기 때문에 한 곳에서 모아서 파악할 수 있는 이점이 있다고 보기 때문입니다. 이건 취향 차이라고 생각합니다. 그냥 MovieSearchContract.View 대신에 MovieSearchView, MovieSearchContract.Presenter MovieSearchPresenter를 사용해도 동일하니까요. 어떤 쪽을 사용하든 가독성에 영향을 주지 않는다면 같다고 봅니다.
MVP패턴이 MVVM(엄격히 말하면 ViewModel + LIveData) 이 나오기 전에는 제일 많이 사용이 됐었는데, 문제가 configuration change나 process death에 대처할 만한 적절한 방법이 없어서 모든 함수에서 view가 널인지 체크해야 하고, 무엇보다고 view가 결국은 Activity나 Fragment의 인스턴스라 Presenter에서 View에 대한 레퍼런스를 가지게 됨으로써 별로 권장하지 않은 패턴입니다. 물론 전형적인 MVP는 보여주신 코드같은 구현이지만, 이게 MVP의 구현방법이다라는 정답은 없습니다. MVC, MVP, MVVM은 그냥 디자인패턴의 개념이고 구현은 개인마다 달라질 수 있습니다.