I object on a few fronts.
One is that the rewrite has 'mechanical sympathy' with the machine e.g. arrays without pointer chasing can fit more data in CPU cache with fewer stalls while it reads over the main memory bus and waits after every item. That should not be a surprise, it's knowable in advance. Why deliberately ignore knowledge about the machine when designing the code, then come back and use that knowledge?
Another objection is to the idea of "measure then improve". Imagine a delivery truck which loads parcels without checking their weight first, then drives the truck onto a weigh machine (profiling), then if the truck is overweight they unload each parcel, weigh them individually, find the one heavy one filled with lead weights, then repack the truck without it. That would be silly and inefficient, right? Now imagine they unload the truck and there's no single parcel which is surprisingly heavy and instead the goods have been packed with 'lead foam'. Who could forsee that would cause problems with the weight on the delivery truck? (Anyone!). Now what's the fix? Unpack and repack every parcel, rewrite the whole code. There's no accidentally quadratic here to remove, instead every tiny piece takes a few more microseconds than it needs to and those add up.
Another objection is "YOU FOCUSED ON IT' - this implies that there is some way you can design and write code that doesn't need any focus. Part of the point of the video is that the faster code is not harder to write, there's no complex algorithms, no compiler intrinsics, no deep knowledge; it doesn't take a focused performance expert to write a switch(){} instead of a subclass.
Another objection is your implication that performance shouldn't be a consideration until you measure it and find a problem, and prove that it is. Which is like saying that aeroplane design weight doesn't matter until after you build it and measure it and prove that it matters. Computers are finite and limited, why have we got to the stage of assuming they are infinite and unlimited, and then demanding proof that they aren't, over and over on a case-by-case basis? A 3D game can render a virtual world at 100 frames per second. Does a program which takes 3 seconds to show a username/password login prompt need enough resources for 300 frames of game until proven otherwise?
Another objection is that you are defaulting to 'clean code is the default, performant code needs measuring and benchmarking to justify itself in every individual case. Why isn't that the other way around? Less resource-wasting code as the default, and 'clean code' only when maintainability has been measured and proved to be a problem, and only in the parts of the codebase which have the highest maintainability problems?
If all the clean code, encapsulation, isolation, abstraction layers, are providing the developer benefits that are claimed - why aren't programs better? If it's now so clean and easy to refactor, why doesn't that translate to software that gets better instead of software that gets worse? Casey's example is that Visual Studio debugger updated the watch window in realtime while stepping through code, on single core Pentium 4 with 512MB RAM, and now on a modern multicore machine with 64GB RAM and an M2 SSD it can't do that. (RemedyBG can, so it's not impossible).