I remember from my intro micro-econ class in college, there were two versions: Econ H200A (with differential calculus as a pre-req), and Econ H200 (without).
I took the former; they explained the concept of "marginal" with one word: "derivative". The latter apparently had to spend rather more time discussing that concept.
You overhype.
Everyone involved has to be sure what is being asked for and what progress has been made so far.
Not everyone, there is no obligation to be sure, and knowing anything with certainty is a questionable standard.
But to measure progress one needs to know what constitutes progress.
Not always. You can use your intuitions without understanding them. It helps of course, but not a requirement.
But to approach a solution, first and foremost, one needs to formalize the problem
Not at all first and foremost. Lots of problems have been solved without having been formalized. Again, it obviously often helps, but not a requirement.
which in turn means to be highly specific about what would constitute a solution.
Not "highly". If you are starting to work on the mystery of fire, you should refer to it as "That orangey-bright hot stuff over there," and not "An alchemical transmutation of substances which releases phlogiston." (although that would possibly be a different error).
And only by being strictly technical and by constantly trying to reduce any vagueness one can effectively approach the formalization of a problem and its eventual solution.
Again, false.
To be technical means to be more formal.
Not necessarily, at least not in any sense of surface appearance. See Three stages of rigour by Terrence Tao. (Use the formal ruleset to train your intuition.)
— Stephen Hawking, in his book A Brief History of Time
Whoever gave this advice to Mr. Hawking is probably partly responsible for the success, financial and otherwise, of his book. But as Paul K. Feyerabend said: "All methodologies have their limitations and the only ‘rule’ that survives is ‘anything goes’."
Open access online communities interested in high quality and productivity can benefit from a high degree of technical formality, including large amounts of mathematics.
Troll Filter
— Alfred Marshall
Another valuable advice in and of itself. But expressing technical issues in a natural language can be a mixed blessing.
Everyone can understand natural language, or so they think. Often any understanding solely arrived at by natural language is vague and can lead people to mistakenly believe that they understand the issue in question sufficiently.
— Mark Chu-Carroll, The Danger When You Don’t Know What You Don’t Know
The introduction of formal language and a focus on hard problems filters out a large subgroup of people who might otherwise believe that they are eligible for membership, able contribute something useful or that the community is interested in their critique.
Less Vague
— Terence Tao, The “no self-defeating object” argument, and the vagueness paradox
Terence Tao thinks that real insight only kicks in "once one tries to clear away the fog of vagueness and nail down all the definitions and mathematical statements precisely." This is another advantage of being technical as it introduces a high degree of focus by tabooing colloquial language and thereby reducing ambiguity.
To be technical means to be more formal. Formalizing problems is itself a problem that needs to be taken seriously as it is part of the eventual solution of each problem. Formalizing a problem is increasing the productivity of people who work on that problem by being more specific about what exactly it is that needs to be solved and by serving as a measure of progress.
Measure of Progress
Being technical helps to facilitate the structure that is required to enable open research and collaborative mathematics.
Everyone involved has to be sure what is being asked for and what progress has been made so far. But to measure progress one needs to know what constitutes progress.
Progress ultimately means to approach a solution. But to approach a solution, first and foremost, one needs to formalize the problem, which in turn means to be highly specific about what would constitute a solution. And only by being strictly technical and by constantly trying to reduce any vagueness one can effectively approach the formalization of a problem and its eventual solution.