what are you going to do instead? just submit the entire thing in one go? go ahead!... your engine will start to struggle on complex maps due to all the extra overdraw that you're now doing.
as a partitioning scheme, bsp is just as valid as its always been.
(yes, it still does lightmap animations)
the trick is to not give a damn about frustum culling. once you've done that, you can cache your batches between frames, and once you've done that, you're drawing the entire world with a single draw call, with the only overhead being a point-to-leaf call and a check to see if it changed.
note that you still need the bsp for the pvs, so that you're only using textures that are actually likely to be seen, as well as avoiding overlapping surfaces that have no chance of being seen.
this aproach beats quake's aproach in pretty much every case, the primary exception being if you've got geometry with unique textures behind you (note that bindless textures or texture arrays will massively mitigate this). The other case is if your gpu's vertex processing is weaker than the cpu, which is rare nowadays.
model rendering, with 512 models per glMultiDrawElementsIndirect call, drawing a grid of 65k individually (well, progmatically with different) animating entities in no particular order.
windows+sdl binaries, includes source.
this thing's performance pwns my own engine too, but is so much more limited, from-scratch rewrites have that kind of problem.
bsp, kdtree, quadtree, octtree, these are the main aproaches, and not using anything is crazy talk. you still need the tree, you just want to take the emphasis off it. q3map2 gives jumbo leaves, for instance with multiple logical surfaces merged into a single trisoup surface/mesh, whereas my onedraw thing caches everything instead to avoid rebatching.