Here's the thing: there's no one right UX, and building your dream UX (even if just for internal testing) takes JS skills.
The argument for having a field labeled Email Address be always-on is you want to make sure the lead gets the chance to re-identify her/himself. But there are two sub-cases that are very different:
One case is if the lead means to say I'm the same human, but I'd rather use this address. You can't use the actual Email Address field in Marketo in this case, because if the lead changes that, Marketo will create a new lead. You instead want to use a proxy field (the equivalent of "user-supplied email correction") which is a field that can be used (on the back end) to change the associated email address.
The other, very different case is when the lead means I'm a different human using this browser now. In this case, you do want a new lead to be created, and you do want the actual Email Address to be posted with the new value.
Navigating the differences between these cases requires developer assistance and some firm planning, to be sure.
Granted, the above is only the barest introduction to your question. (Save for my firm view that Email should be one of your always-ons. Although that may -- and perhaps should -- mean an always-on but read-only field that only allows editing when a lead clicks a Change link/pencil icon, etc.)
I think once you get First Name and Last Name, those can be hidden or read-only fields for subsequent fillouts. They should not be editable fields unless the person chooses to edit Email. It is vanishingly unlikely that someone will want to change FN or LN without also making a change to their email, and showing that you understand that makes the form more "human."
So in all of the above cases. we're talking about a third class of field -- the conditionally editable but always-on field.
Opt-In and Comments are two other fields that are typically always-on (and always editable) in my experience. The first is self-evident. The second allows the lead to post questions alongside each form fill: no reason to prevent that. On the back end, you can append that data to a history field that stores all their notes over time.
There are many interesting UX questions around ProgPro. I'm glad you're asking them because people tend to leap into "that'd be awesome" and back out to "that wasn't at all awesome, let's turn it off" due to poor planning.
.png)