It is partly historical notoriety. It allows one to prove certain statements that seem counter-intuitive. So proofs that employ it can often be viewed with some skepticism.
Moreover, this axiom is _independent_ of the other axioms in ZFC. It is in fact possible to have entirely self-consistent "worlds" of mathematics, ones where axiom of choice is true, and ones where it is false.
If it seems weird that math can give you contradictory results, remember that the difference only shows up when you deal with some form of infinity (e.g. when performing an operation on an infinitely large set). For any usage of math in the real world, the truth or falsity of this axiom won't give you contradictory results.
One of my highest-cited papers didn't pass peer-review. But that's okay. The citations (of the pre-print version) speak for themselves. If papers like these are good enough that new students entering the field use it as a ramp-up resource, they won't hesitate to cite it over and over again when they submit something for peer-review.
So journal publication is not the only means of recognition.
Speaking of which, computer science is a bit weird in that conference papers tend to have higher visibility than journals, even though the latter still has some of its grandfathered glory. Not all conferences are equal, obviously. Some have a more rigorous submission process than others. But our field definitely carries a bit of skepticism about the value added by journal publishers.
If they have customers who need that kind of database, I'm sure they will be willing to help out with the testing. The setup doesn't have to be too crazy. Storage appliances with 20-30 hard drives are fairly common, actually. Even for individual humans, not just corporations. LVM allows you to easily create a logical volume out of multiple physical volumes, e.g. https://www.redhat.com/sysadmin/creating-logical-volumes.
> SQLite was originally designed with a policy of avoiding arbitrary limits. [...] Unfortunately, the no-limits policy has been shown to create problems. Because the upper bounds were not well defined, they were not tested, and bugs were often found when pushing SQLite to extremes.
The material nature of hardware is barely any higher than that of software. Yes, you cannot just copy bits around, but you can take the same design and fabricate millions of chips for pennies. The cost of production for any given chip of Silicon has almost nothing to do with its material cost. It has everything to do with the amount of design work that went into it, just like software. None of that appreciably changes the benefits of cooperation vs competition.
I haven't looked at your past blogs, but it certainly sounds like you are making perfection the enemy of good. Your blogs don't have to be perfect, it just needs to be better than the current state, while not causing unanticipated regressions. Your blogs do not have to be prescriptive either. All you have to say is: I've tried x, y, and z, and it turned out better than a, b, and c in this-and-that manner. Provide your argument, and let readers judge whether your advice applies to their situation.
That said, if you do not have actual data or experience to back up what you are preaching, I definitely welcome the call for caution. It is not useful to insist that "everyone should learn a certain skillset" unless you found those skills relevant in practice in some situation.
It sounds like you've been compiling an interesting collection of stories, ones that might be interesting to a lot of folks here.
The comparison is fair because it tries to automate expertise.
I'm sure you know exactly how much of which filter to apply for similar results. Laymen like ourselves will need a lot more trial and error. Their contribution here is to provide a push-button, automated mechanism.
I would have probably also tried something simple and given up due to the noise. So this is definitely interesting.
Have you ever tried wiring any non-trivial logic without flip-flops? Say, a simple signal routing layer. Even the most basic bits of logic becomes much less efficient to downright impossible without storage.
That is sounds more appropriate for either terminating the program or resumable exceptions like division by zero. In languages with a try-catch construct (specially C++), the complexity of implementing exceptions has to do with stack unwinding. This is where you don't want to restart in an outer context, but want to guarantee cleanup for the call frames you are abandoning.