Reading this, the partial first answer the author started with was, in fact, a bad answer. Where the MVC pattern is used was not really relevant to the question.
Not to mention, the second answer is correct. Three-tier architecture and MVC don't have to be exactly the same to be related and have major elements that correspond to each other.
Going deeper, if anyone is interested... it's pretty common in MVC for the view to point at elements of the model. To make it more concrete, imagine a Circle type composed of x, y, and r and a CircleView that displays a Circle. The CircleView might point to an instance of Circle that is also in the model. But as long as the controller put in in the view and the view know it's from the model, that's a perfectly valid MVC (IMO anyway. People will argue about this.) Interestingly, a similar situation arises in a three-tier architecture where storage is able to directly serve resources over standard protocols. E.g., imagine an application to store and share images where the images are stored in KV store that also has an HTTP interface (like S3). When displaying images, the app layer could render HTML to the browser client with <img> elements where the href links directly to the storage. The client would then bypass the app layer to access the storage itself. This is perfectly valid for the same reason as the MVC case -- the client doesn't know or depend on the fact that the resource is directly from the storage, and the middle tier is what controls what the client it going to access.
Not to mention, the second answer is correct. Three-tier architecture and MVC don't have to be exactly the same to be related and have major elements that correspond to each other.
Going deeper, if anyone is interested... it's pretty common in MVC for the view to point at elements of the model. To make it more concrete, imagine a Circle type composed of x, y, and r and a CircleView that displays a Circle. The CircleView might point to an instance of Circle that is also in the model. But as long as the controller put in in the view and the view know it's from the model, that's a perfectly valid MVC (IMO anyway. People will argue about this.) Interestingly, a similar situation arises in a three-tier architecture where storage is able to directly serve resources over standard protocols. E.g., imagine an application to store and share images where the images are stored in KV store that also has an HTTP interface (like S3). When displaying images, the app layer could render HTML to the browser client with <img> elements where the href links directly to the storage. The client would then bypass the app layer to access the storage itself. This is perfectly valid for the same reason as the MVC case -- the client doesn't know or depend on the fact that the resource is directly from the storage, and the middle tier is what controls what the client it going to access.