While we're on nav meshes and airstrafes, this touches on some quite interesting problems in video games and also robotics more broadly.
If you create a map, there are clearly some areas that are not traversible. A human player can find them easily by visual inspection, or by colliding. And we have millions of years of intuition about navigating through 3d space. But how could a robot know which areas those are?
TF2 solves this problem by computing a nav mesh, which is basically a big list of polygons that are "cells," in a datastructure called a graph. Each graph node (a polygon) has some edges that connect it to other nodes (neighboring polygons). Then, if you wanted to navigate from one point to another, you can traverse the graph using an algorithm like A*, which will create an optimal (least distance) path from one point in the graph to another -- and hence, one polygon location in space to another.
If you have ever typed nav_generate on a tf2 map to make a navmesh, you will notice that this task takes your computer several seconds. That's because it has to split the map into a bunch of tiny, probably triangular polygons, with nodes and edges representing how they are joined. Then, when the bots navigate, they can just call an A* algorithm according to their combat logic to move around.
So that is probably how the bots in TF2 move around: precompute a nav-mesh, then do A* (or a variant of A*, there are many). Although I haven't seen the secret sauce.
But there's a special property about robots called holonomicity. Basically, holonomicity says that the movement of the bot through the space does not depend on it's current position. An example of holonomic movement (at least on the 2-D plane) is the bots; you can press WAS or D, and you can stop on a dime and turn completely around regardless of where you are moving. This property makes path planning much more simple, because you don't need to worry about your current velocity vector (or higher order derivatives) when computing your future path. Non-holonomic path planning is much much harder, though: think of an airplane traveling through the air. That is a non-holonomic vehicle. If you want to move from your current position to the position that is just 1 meter to your right in an airplane, you might need to make a series of complicated turns and maneuvers -- you can't just like press a button and move sideways!
If your position at t=1 depends on your velocity and position at t=0, then some areas become inaccessible depending on your velocity at t=0. And, not only that, but the path you take from t=0 to t=1 actually affects your velocity, then if you want to say "I can get from point x0, y0 to point x1, y1" you need to compute many many velocity/position pairs. In fact, you need to compute so many velocity/position pairs that the problem is NP hard at least -- probably worse than NP hard. That isn't even to speak of collision calculation!
So, airstrafing. Airstrafing introduces non-holonomicity. Why? Because during a strafe, you are set to move through the air according to how you jumped or got bounced. Like the airplane, you can't just press "S" and move left of where you are; you have to alter your heading, and then actuate with a movement key, which changes your velocity vector a little bit, and then you're at a new position, thusly influenced.
And even still, there are some areas that are inaccessible to you in an airstrafe. You can't move in like an L pattern for example, like with a sharp bend, there has to be some minimum curvature. Probably, the equations of motion of an airstrafe have some derivative (velocity is the derivative of position, acceleration the derivative of velocity, etc) terms. Which means that an L shape path would violate your equations of motion, as it is not differentiable! You can move through an L-shaped path on the ground: press W for a bit, then S. Not so in the air!
I suspect this is why airstrafing is so interesting and fun as a game mechanic: your motion during an airstrafe is just so much more complex, and it's so much more difficult to find paths, because of all of the aforementioned factors.