If you use ASP.NET WebForms, there are indeed a couple of aspects that will enlarge your HTML. They can be mitigated to an extent, some more easily than others, and improvements have been made particularly in .NET 4.0.

• As you say, there is the hidden __VIEWSTATE element which WebForms uses to maintain the illusion of statefulness. This is turned on by default, and if don’t touch it, it can easily add a lot of unnecessary weight to a page with a lot of controls. If you’re not actually using it, though, you can turn it off on a page or a control with EnableViewState="False".
• If you use the more featureful Web Forms controls, you can do some rather rapid development, but you can also produce a lot of generated HTML which isn’t really under your control, and could well be a lot bigger than is necessary for the subset of functionality that you need. In my Web Forms days, I found that a lot of developers (myself included) shied away from the more powerful controls because it always felt like it saved you time in the beginning but ended up costing you more time later on, as you fought with it to get the precise result you needed.
• If you architect your pages in an easy-to-maintain fashion, with master pages, pages, and various user controls, you’ll find that Web Forms’ name-mangling of IDs (to guarantee uniqueness) will lead to some rather long IDs on HTML elements, thing like id="ctl00_AGSMasthead_imgSkipContent". This has been improved in .NET 4.0 – you can use the new ClientIDMode="Static" property to tell Web Forms that it does not need to mangle the ID, you’ll maintain uniqueness yourself.
• Because Web Forms uses the ID of a control to refer to that control in server-side code and as the ID of the element in the rendered HTML, it often leads to you having a lot of HTML elements with IDs that are never used client-side by CSS or JavaScript, and are just wasted space. This is one of my main dislikes of Web Forms, by the way. You do something like <asp:Label Id="lblName" Runat="Server"/> so you can populate a label in the code-behind, and it gets served up as <span id="lblName"> – or in the old days, more likely, something like <span id="ctl00_ucHeader_lblName">. So unnecessary, personally I wish that instead of the Runat="Server" attribute, they had designed something along the lines of ServerID="lblName" which both identified a control as being server-side and assigned a server-side ID which was separate to the client-side ID (if any).

Ultimately, you can work around most of this to some extent, but if you use Web Forms in the fashion in which it is designed to be used, you will get some weight added to the HTML you serve which is not strictly necessary.

However, I think that the difference in weight between a Web Forms page and a page produced by some other platform and framework is probably less than the difference between a poorly coded page and a well coded one which makes good use of clean semantic markup, minimizes unnecessary tags and attributes, uses clean unobtrusive JavaScript, etc.

ASP.NET as you have indicated does use the ViewState. First of all I’m going to briefly explain the purpose of the ViewState and why it is there.

What is the ViewState

In a nutshell, the purpose of the ViewState is to preserve the value of form fields between postbacks. From that statement, you can infer then that the more fields you have, the larger your ViewState is going to be.

In addition to preserving the value of form fields between postbacks, you can also store arbitrary data inside of the ViewState, by using ViewState[key] = value.

You can, however, disable the ViewState, either on a page level or element level where it is not appropriate to use. This can also save space in the ViewState.

How

The ViewState is stored as a hidden form element that is posted to the server when you submit the page. The following diagram demonstrates the key points in ViewState processing:

_{(source: microsoft.com)}

The key points here are LoadViewState and SaveViewState. LoadViewState loads the data posted to the server, where SaveViewState serialises it for storage in the ViewState after page events have been processed.

Advantages

The primary advantage of using the ViewState is to persist data between page loads. For example, when the page is first loaded fields may be populated with the results of, for example, a long running database query. Subsequent loads can use the values in the ViewState to save re-executing that query.

Relation to ASP.NET MVC

ViewState is not at all relevant to ASP.NET MVC and is a component of ASP.NET Web Forms.

Equivalent in PHP?

There is no equivalent in PHP. You could manually implement the functionality if you so desired by serialising for example your model and reloading it on POST.

Do you have to use the ViewState

No, you don’t. If you turn it off, your page output size will decrease but you will also need to factor in the overhead of reloading data.

TL;DR and to the question

Will the difference between the size of PHP pages and the generated HTML of ASP.NET pages be dramatic?. The answer is it depends on what you are outputting. If you are making massive forms and particularly if you’re making use of controls such as Asp:DataTable then yes, your output could be significantly larger. I’ve seen ViewStates grow to over 1mb. You need to bare in mind that on each submit, the entire ViewState has to be uploaded to the web server. If you’re producing small and simple forms, the size difference is going to be negligible. YMMV depending on what it is exactly that you’re doing.

The other thing to bare in mind is that in PHP you have a lot more control over the generated markup than what you do with WebForms.