Do you have a link or can you elaborate on the part about using al_draw_prim()?
Unfortunately, no. I'm speaking from experience in that, al_draw_prim() has a huge overhead cost to call, but can send massive amounts of data to the video card in that single call, so if you use it correctly it can be very powerful and can perform better than multiple al_draw_bitmap() calls, but to use it, you need to manually assign all of your texture coordinates, triangle coordinates, vertex colours, etc., and put them all into a massive array you can send to the function.
Beyond that, just read the manual.
Also, I don't particularly require 9000 sprites and certainly not 50k per frame, but I wanted see what the max was without any game logic so I could bench mark how badly various bits of game logic are slowing the game down... I just figured that if i started with the ability to draw 50k, it would give me more wiggle room for AI, and path finding then if i started @9k... does that make sense or am I thinking about it wrong?
You're thinking about it wrong. You'd be surprised how much game logic you can process without affecting the framerate on today's computers. Heck, I was running particle engines at 70 FPS using Allegro 4 back in 2000 on original Pentium CPUs.
Plus, if your game logic DOES slow the game down, there's almost certainly going to be alternative approaches. For instance, if you have a massive tile-based world and various objects in that world can update themselves at random, instead of scanning every single tile every game tick and performing those random calculations, you could just scan a handful of random tiles and make it more likely the random tile event will happen when it gets scanned. Or, if you have tile entities that need to constantly be updated, instead of scanning the entire map for changes, you make a list of each tile that needs to be updated every game tick and update that list as more such tiles are placed or removed.