Personally I think you shouldn't use the octree as a pathing graph and instead should create a more appropriate graph.
I agree. It is without any doubt possible, but the question should really be "does it make sense, is it the best thing?".
Pushing back the question wheter an octree is very suitable at all for a moment...
Do you strictly need 3D pathfinding at all? Most people do well enough with "2D and some", and not few even only do 2D at all (without the "and some"). Plain 2D is sometimes a bit poor with flying units that cannot cross water and such, but still "and some" is normally good enough, you rarely need real 3D. Adding a node that is for flying units only usually does the trick. Most units don't move in 3D anyway, and if they do, they don't truly
move in 3D if you take the ground as a reference, or hardly.
The only things I could ad hoc think of that really need true 3D pathfinding would be a dungeon maze with several levels, aerial combat simulation, or space games. Everything else either walks on the ground, or has some flying abilities, but still mostly-walks-on-ground for practical purposes.
Mazes are not normally large enough to justify an octree. Also, in a maze, agents usually don't need to pathfind from the bottom to the top. It's the player's task to do that, and monsters are usually per-level 2D beasts... If monsters are able to track the player up the next stairway, that's already almost revolutionary (how many games do that!) -- and this can be easily done with one extra node over the stairway.
Airplanes really only need to care about not flying into a mountain or tower, the rest is more or less "straight line through mostly empty space", so that would be "2D plus". Shoot at enemy airplane? Draw a line.
Yes, in real life you have flight levels and corridors, but that's a different thing, and it isn't a pathfinding problem either. There's a well-defined course and altitude which you must follow, and you have no questions to ask or think of a better route (flight control tells you exactly what to do).
Similar for space sim. Most of the universe is empty, and "draw a straight line" works 99% fine. And when it doesn't work, you just have to "bend" your path ever so little so you don't fly through a star. So basically, draw a straight line, and see if it collides with the bounding sphere of something of planetar size. Unless you want something like navigate fully automatically through a narrow passage between two hostile territories, I don't see how there's large demands on path finding there.
There's that "hierarchical pathfinding" thing of course, or the "hierarchical AI" thing in general. Which has its merits. But an octree (or let's say quadtree) still doesn't seem like the necessarily best approach. I'm using a "somewhat hierarchical" regular grid representation for the world myself (with three levels alltogether) because I like the idea that you can just stop simulating what no player can see, and I'm cheap. But pathfinding itself is in fact embarrassingly poor, yet it works entirely satisfyingly (indeed, it being poor accounts for the fact that units are not omniscient, which is desired).
That hierarchic stuff is not a free lunch alltogether anyway, there is a point where things turn around, and it's hard to predict where and when. After finding a path within high-level nodes, you still have to pathfind within each high-level node, and if these are huge, they contain a lot of child (grand child, grand-grand child, ...) nodes, which are added to the sub-search again. It still prunes a lot away, but it's not a free lunch alltogether, and infinitely. Plus, unless you put a lot of extra work into it, there is a good chance of getting a rather sub-optimal path (which is not always undesirable, more perfect is not always more good).
I haven't ever tried the octree approach, so everything here is just guesstimate. But the mere added complexity paired with the uncertainity whether it really adds a lot turns me away.
There's that thing called cache, too. Octrees are one of those structures which look awesome, and perform awesome -- on paper, looking at complexity numbers, and also in some real-life situations. And then they fail miserably in other situations, solely because the way you access them doesn't play well with the hardware. There are some access patterns (and I am afraid A* might exactly be one of them!) which are catastrophic worst-case to an octree (unless the whole octree fits into cache, and in that case it's so small that it's pointless).
I remember (unrelated to pathfinding) an article some 4-5 years ago analyzing Minecraft-like engines which concluded that although octree is what everybody intuitively jumps onto, it fails performance-wise because of iteration being the main operation.