That example is a scam, you're comparing accelerating physics calculations with collision detection to moving sprites in a linear Add 10 to Object.Y without any collision detection or acceleration, it'S smoke and mirrors and completely non functional.
Maybe not a good example but i think the point he wants to get across is to identify when and when not to use certain features such as physics. If you can do pretty much the same thing without physics and save a lot of CPU calculations then I would call that an optimization. Many people just go the lazy route and slap on behaviours such as physics when you can do similar things way more lightweight with events (depending on what you're trying to do) but sometimes there's no way around it.
I'm using a similar approach for the arrows in my game. Instead of checking collisions every tick for the arrows while in the air I'm just moving sprites.
When an arrow is fired, I make a very lightweight raycaster with events to calculate a line between player and where the arrow should land or collide. This happens in one tick. No need to check collisions every tick after this point, since I already know where the arrow will end up. After that I just move a dummy sprite from point A to point B. The arrow sprite follows this dummy sprite, and is offset in Y axis based on the distance travelled to simulate and arc.
So instead of checking collisions every tick, i just check it once in one tick, then just move objects accordingly.
One huge part of optimization is to determine when to use what, and If you can get a similar effect but simplified. Collisions can be very useful, but can also use a lot of CPU if you're not careful.