If anything could be called a mistake here (which I am not really arguing in earnest), it was Arduino’s “mistake” to release any 5V boards to begin with. In retrospect, it likely would have been smarter to use 3.3V from the start.
I do believe the reason was the clock limitations on ATmega328 and other AVR MCUs. If you look at Figure 31-286 in the
ATmega328 datasheet, you can see that the core frequency is limited by the supply voltage. While at 4.5V and higher supply it can do full 20 MHz core clock, at 3.1V it is limited to 12 MHz; at 3.0-3.6V typical 3.3V supply range, you're limited to about 11 MHz — or only a bit over half the maximum it can do. Other AVR cores like ATmega32u4 (with native full-speed USB) are similarly limited: the SparkFun Pro Micro (based on ATmega32u4, with native full-speed USB interface) even came in
both 3.3 V / 8 MHz and 5 V / 16 MHz variants. (As it is CC-BY-SA, the Pro Micro clones you can buy are copies of this, with Caterina bootloader (as on Arduino Leonardo).)
_ _ _ _ _
I often use Teensy 4.x via Teensyduino Arduino add-on for ad-hoc tooling myself. It runs at up to 600 MHz by default, although you can overclock it to almost a gigahertz if you ensure it stays cool enough, so microsecond precision is achievable (it's
6 600 clock cycles per microsecond). A simple loop can toggle a set of GPIO pins at about 180 MHz. You cannot use JTAG with it, because it has a proprietary
bootloader chip (that you can buy off PJRC; the boards themselves are nowadays manufactured by SparkFun), but at power on, the full IMXRT1062 (except for JTAG) is at your disposal, including full 1Mbyte of SRAM. Because it has a native high-speed USB interface that can push 200+ Mbit/s (21 to 29 Mbytes/sec depending on host) over trivial USB Serial (USB CDC ACM, generic USB serial drivers) while doing other proper work — my test uses a PRNG that passes all BigCrush randomness tests, unlike e.g. Mersenne Twister, and verifies the host-generated sequence matches — it is an excellent base for ad-hoc tools, like interfacing a computer to external devices.
For me, the Arduino environment is mainly an ad-hoc toolbench, which allows me to cobble together very high-performance interfacing tools in no time. I also have lots of various logic level translators and isolators in stock, because my devices' GNDs don't always agree, so ground loops are a problem I need to be aware of.
For any
serious work, I do prefer a plain
Makefile-based build environment; but for the modular initial testing, and even code development, I use whatever editor or IDE I find most suitable. I have the luxury of no deadlines, so I choose not to copy-paste code from anywhere, ever, and instead
adapt preferably-minimal code to each use case (and keep a library of thousands of pluripotent algorithm test cases to refresh my memory). So, I my needs and use cases may be unusual, but I do claim I am quite
effective (albeit not
fast) this way.