Forms and MVC are not that different. Remove the ViewState and add a fancy http request handler to ASP.NET WebForms and you end up with ASP.NET MVC. Both frameworks share most of their code. 

Scaling a Forms application is not harder than scaling a MVC application. You must solve the same problems: synchronize file systems, session state and data cache between instances. The solutions are the same.

But the ViewState is a problem. Not because of it's design, but because of how it's (mis)used. Unfortunately Microsoft decided to turn it on for all controls by default. Most programmers don't now how and when to turn it off. The sad fact is that 99% of all the viewstate served by ASP.NET WebForms applications is unecessary bloat. It's not uncommon to see sites with hundreds of kilobytes of viewstate data. All this data is sent back and forth with every page request and postbacks including many ajax requests. That won't scale. And the site will feel slow for every user even when traffic is low.

If all developers would learn how to deal with the viewstate, the problem would be solved. But, that's not going to happen. Customers need to check the impact of third party modules have on their viewstate and spend their dollars accordingly. 

The biggest problem with the ViewState is that you need to make the decision if it's needed for each individual control on a web page. 99% of the time, it is not needed. But still, you cant just disable the ViewState for all controls, because most pages have one or two that needs it's viewstate. Unfortunately, lousy developers keep it on for every control because they don't understand it.

The only thing Website owners can do about the ViewState is to be careful about the skin and modules they put on their site. Choose skins and modules from vendors and other sources that doesn't impact the ViewState too much. No page needs a big viewstate. A big view state is bad programming. Used correctly, the viewstate is the best solution for some tricky problems.