This is one of those things that's technically true, but misleading.
Without scripting, you can't do any client-side validation, so you have to submit the form.
Without scripting, it's then harder to repop the form for the user when it fails.
I'm not saying things aren't excessive today -- they clearly are. But tossing client-side scripting entirely seems like a baby/bathwater situation.
Even more, html validation has by far a much better UX than most custom made JS solutions. For example if there is an error in the validation, your cursor is immediately transported to the offending field where you can do the correction, with the appropriate css classes available to highlight the field properly.
And for the stuff that html validation is not powerful enough, well then you most probably want to check that on the server as well anyway.
+ client-side validation is not validation.
Since you're doing the server-side validation you have to do anyway, it's child's play to return the HTML form with the values the client submitted pre-filled.
Client-side validation is a user convenience; it's awesome, but not sufficient in itself, because it can only protect the client, not the server, from invalid values.
Repopulating the form on the server side after validation failure is trivial and even more so when there are libraries that abstract that away (eg. wtforms).
On a similar note I somehow fail to see the benefit of writing (and often duplicating) large parts of business logic in client-side javascript and replacing perfectly good HTML form-submission mechanism with random JSON "REST" APIs.
> Repopulating the form on the server side
> after validation failure is trivial