Goodhart's law is entirely applicable to management (adding scientific in front doesn't actually mean anything). That is one of the prime areas of applicability. People change their behavior to increase a metric at the cost of decreasing other more important things.
The obsession with measuring is hilarious. There are plenty of things in life (and jobs) that aren't measurable and are worth doing. Probably all of the important things are actually unmeasurable. Think about it this way, if its so easy you can measure it, it probably isn't very important in the grand scheme of things.
Even in the first years, they suffer from the simple fact that you can't present something correct and useful in a small popular talk with no pre-requisite shared knowledge. Its "empty calories" that makes it feel like you learned something but its really just entertainment. Neil Postman in "Amusing Ourselves to Death" regards these types of talks as more pernicious than things like reality TV that don't claim to provide any useful information.
Analytics forecasting doesn't really seem like a good candidate for deep learning. There are plenty of established methods for forecasting that are simpler, more robust and generally more effective in terms of effort to reward.
Note, "80 / 100 of these functions are never called. I'll just remove them from the program image to save load time and locality of reference" is already an optimization compilers apply: dead code elimination.
The other way to phrase that is "A data scientist is a worse programmer than a typical programmer and a worse statistician than a typical statistician." If you need a programmer, hire a programmer. If you need a statistician, hire a statistician. I wouldn't ever hire someone who took a bootcamp that is "a better plumber than a typical doctor and a better doctor than a typical plumber."
I think the problem is in the idea that "you better have some human engineers around in case a tornado forms." That is a completely different job than the original job and the folks waiting around "in case a tornado forms" likely won't have the skills to fix that tornado anymore. The issue isn't that "the robots are going to take our jobs!" its that the new jobs are ones humans actually aren't very good at; waiting around ever vigilant until the automated system screws up and then immediately coming up to speed and fixing the system they no longer have any interaction with.
This is not a very good example of benchmarking. First, all of the benchmarks need to be run multiple times e.g. -count=5 at least to get reliable results. Second, benchmarking like this is really meant for analyzing a single operation. It confuses the analysis when a repetition of 1024 operations is benchmarked so that the numbers have to be divided by 1024 to get comparable numbers. The golang benchmarking library can reliably measure operations of a few instructions long, so no need to repeat them N times for measurement. Sometimes you will want to see how an operation changes based on something like length, e.g. hashing 8 versus 128 characters, but in those cases the operation is "hashing" and you should have separate benchmarks to measure performance versus different lengths, which is a great use case for sub-benchmarks r.Run(). Finally, as others have mentioned, most of these are micro-optimizations that make your code less maintainable, e.g. you should always iterate over a slice with range unless you have some logical reason not to.
The string benchmark has the issue that the amount of work done varies with each pass through the loop since the string just keeps getting appended to. A proper benchmark like the ones in the comments here do the same amount of work for every loop.
It deals with floating-point, arbitrary-precision decimal numbers, whereas math/big contains support for arbitrary-precision integers, rationals and binary floating point. Looking at it briefly, it looks like it uses math/big under the hood when the numbers are large, but uses an internal compact form for efficiency when numbers are small ~<= 20 decimal digits.