We're discussing which abstraction is between the backend/front end. You said, to use Blazor safely, I also need to deploy WebAPI. I said you therefore need to test and develop it all twice: Blazor and WebAPI.
So you would build a solution that combined both using Blazor? I still don't understand, this is just like if you were to build a WebAPI and a front-end JavaScript SPA, except Blazor is your JavaScript SPA. You have your unit tests for your WebAPI, and you have your tests for your JavaScript SPA (in this case Blazor, but fill in Vue or React, etc.). You could then write integration tests if you wished, but there isn't any more testing or development process than if you were building a WebAPI with a traditional JavaScript SPA. Blazor is just affording you the ability to use C# rather than JavaScript.
If you were to include your business logic directly into your Blazor application, then you are setting yourself up to run into the exact same issues that you faced with WebForms, if Blazor were to be discontinued. You stated, "Stick to WebAPI and put whatever you want in front. That way you can migrate either front OR back independently of one another (and or do piecemeal migrations)." Blazor is what you put in front. Blazor gets discontinued, you put a standard JavaScript framework in front. The amount of code written and the amount of tests written should be the same whether you use Blazor or React/Vue/Angular/Svelte/JS Framework of the week. What you get with Blazor is the ability to do all your front-end in C#. I think you are going at it as if you build old WebForms or Silverlight, and I just don't see why you would do that knowing full well that front-end tech changes rapidly.
