Some people like comments. I, for one, find them interesting. Others may be interested in how PerlMonks has the HTML structured, and they don't feel like running it though a beautifier every time. After all, we want to encourage learning, and not push away those who are curious, right?

Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.
I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.

That is 168 lines, 3,932 bytes of data sent per page load, less for pages with less content.
What does that tell us? There is:

Commented out code for IE

The name of the CSS theme which is already listed at the top of the CSS file.

No CSS Link in shows us 2 external sources were not configured. Why does a normal end user need to know this?

Information about different parts of the header and title bar

Start a Post with TITLE, REPLIES, AUTHOR, DATE fields

The post comments repeat with slight variations.

Nodelets have breaks!

A commented out link

Containers are closing

That reads like a list of debug statements. It is not a good practice to emit debug statements in production software. Commented out code should never stay around, we have version control for tracking changes. In addition, these comments provide no direct value to the general users of PM. Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them. There are sites specifically designed for that purpose like CSS Zen Garden.

Sure, it would save bandwidth. I don't know how much the server costs for PM, but if it's one of those "unlimited" plans, then it would be rather useless. Again, we seem to have gotten along just fine with how it is now, so there is no real reason for change.

So saving bandwidth is good but we should not do it because PM does not need to change. Right. Delivering a smaller HTML page and CSS files makes the PM experience better. Faster page loads always make users happy and slower pages make users look for alternatives.

I understand that some users have bandwidth restrictions on their end, so perhaps it could be enabled as a setting. That would probably be the best idea.

This suggestion is not the "best" idea. It would require changes to the server software for processing each page on a per user basis. A simpler solution is just to take snapshots of a few pages, do a writeup and include those pages with the writeup on PM itself which is much easier work then editing the server software to add new features. Users can still study how PM works without sending data that is meaningless to most to all users.

And then there is this statement:
After all, we want to encourage learning, and not push away those who are curious, right?

A flippant statement to prop up a strawman argument. Making statements like this just makes you look bad, point of fact.

That reads like a list of debug statements. It is not a good practice to emit debug statements in production software.

And yet, everybody does it. Our good friends in PHP-land have plenty of well-known applications that emit debug statements in many places, as well. Of course, they are PHP users, and PHP people have a rather narrow mindset(but that is a different story), so that might be acceptable to them.

Users are here to ask/answer/learn about Perl not focus on the markup for the content that was delivered to them.

Notice how you basically ruined the foundation of your suggestion?

By the way, did you know that you could also shorten the class names on the elements using them? For example, instead of .pmsig, we could make it .pms. Oh, we would save so many kilobytes on long threads!

When putting a smiley right before a closing parenthesis, do you:

Use two parentheses: (Like this: :) )
Use one parenthesis: (Like this: :)
Reverse direction of the smiley: (Like this: (: )
Use angle/square brackets instead of parentheses
Use C-style commenting to set the smiley off from the closing parenthesis
Make the smiley a dunce: (:>
I disapprove of emoticons
Other