TL;DR
Model View Controller (MVC) is a design pattern designed to keep a separation between the data and how the data is rendered.
ASP.NET MVC uses that MVC pattern, but it's not exclusive to ASP.NET and it's a pattern that's equally valid for populating a web-page on both client-side and server-side.
Razor is one of many syntax that can be used for the 'View' part of Model View Controller.
The longer answer
Taking your two questions separately:
Why is MVC mentioned
MVC can come up for a couple of reasons. Firstly, a lot of people want to incorporate Blazor into existing MVC sites, so you see mention of MVC in that context. Blazor works well there because it's happy to exist alongside another technology (e.g. ASP.NET MVC, and also non-.NET sites).
More generally though, MVC doesn't just mean ASP.NET MVC, it really refers to the Model View Controller design pattern, which is one way of getting a separation of concerns between the concepts of the data rendered on a page (the model), the way thing that is rendered (the view) and the thing that puts the data into the rendering template (the controller).
In ASP.NET MVC the controller lives on the server and place's the model's data into the view there, but that doesn't have to be the case, it's just as valid to get the data on the client (from an API) and then populate the view on the client-side too. This is the way that front-end frameworks like Angular work.
As your Blazor app grows, you'll probably find you want a separation between how the page is rendered, the things that retrieve the data, the data itself and the state of your app. At that point design patterns can help.
Using the MVC pattern in client-side Blazor may seem impossible at first, as the routing resolves incoming page requests to Blazor pages rather than Controller classes as it does in ASP.NET MVC, but, you can think of the Blazor Page itself as a controller. The page is effectively getting data (the model) from somewhere and combining it with the Razor code (the View), which is exactly what a Controller is for.
Other presentation patterns, e.g. MVVM may be useful too, as may state patterns like Flux or Redux.
It's important to note that the Blazor team have said that they are trying to make Blazor pattern agnostic. Here's a quote from Dan Roth on that:
Our goal with Blazor is target a broad audience with Web developers,
so we're specifically not targeting compatibility with
WPF/UWP/Xamarin.Forms. We are also trying to give the you the
flexibility to use the patterns you want without baking too much in
the framework. So you should be able to implement MVVM patterns on top
of Blazor's core concepts
What's the deal with Razor?
Razor is the syntax for describing how all, or part, of a page should be rendered in HTML, i.e. it's the language that can be used to describe how the View in the Model View Controller should be rendered.
Because client-side Blazor is determining how a page should be presented, we need something that we can use to describe that, which is where Razor comes in. Microsoft have chosen to reuse the same Razor syntax/language used for server-side ASP.NET MVC for Blazor, which will already be familiar to developers who have worked with ASP.NET and aid in migrating parts of existing sites to Blazor, as opposed to adopting something like, say, the Handlebars syntax.
'Blazor is supposed to be a SPA replacement'
One note on this: Blazor can be used to build Single Page Apps, but it doesn't have to be used like that. For example, we are using Blazor to add functionality into an existing ASP.NET MVC site. In that case the server renders an MVC page that has a placeholder for the Blazor functionality for that page. Blazor has good JS Interop capabilities so can happily co-exist with existing pages.
