Changes to a functioning system that is in use should be done with care akin to pruning a bonsai tree, not by introducing sweeping changes that are then potentially scaled back.

That would only make sense for posters with, say, negative karma in the last month. Otherwise this results in (self-)censoring of controversial comments.

I very much agree with your proposal, it should have been an obvious first step (and if there had been some public discourse in which you would probably have suggested it, it might well have been). Upon unsatisfactory results, it could have been escalated to a more profound change.

How long is it going to take for some forum regulars to pick up a dedicated downvoter with two sockpuppets, strongly impinging the discussion on their new +0 -> -3 comments, at least temporarily? The karma hit is a negligible inconvenience for old-timers, but the temporary obstruction of their conversational flow isn't. Empowering trolls inadvertently, how ironic. Who would have thought there are such unforeseen consequences when non-professionals implement such changes without discussions? Why, I suspect you would have, as someone experienced with software design failure modes.

It is a bit disconcerting that such an a-priori type proposal was implemented not only without considering expertise from LW's very own base of professionals, but without first gathering some evidence on its repercussions as well. From the resident Bayesianists, you'd think that there'd be some more updating on evidence through trials first, e.g. by implementing similar (such as yours) but less impactful changes first.

Concerning your software development paradigm:

With the caveat of not having spent a long time in the software industry, there is an argument for the converse case as well.

While I'm all for using k-CNFs, DNFs and all sorts of normal forms, penalising lines of code can easily lead to a shorter, but much more opaque piece of software, regardless of doxygen or other documentation. Getting rid of unnecessary conjuncts in a boolean formula sounds good in theory, but just spelling out each case, with e.g. throwing an exception and commenting that this or that case should not happen, can make it much easier for someone else to follow along your logic.

A maximally compressed pile of ultra efficient goodness, resembling a quine in terms of comprehensibility, would satisfy your "minimize the code" requirement, yet make the code less accessible, not more so.

But I'm happy to consider your testimony to the contrary. As the saying goes:

All theory, dear friend, is gray, but the golden tree of life springs ever green.