Given that I'll be generating everything at runtime I'm assuming that 2d toolkit's static sprite batcher is not an option for me. <- the static sprite batcher will work but the tile map will probably be easier to deal with if you're making a tile based level. Still keep the static batcher in mind - its pretty useful if you want stuff which isn't part of a tiled level and constructing one at runtime is pretty fast too.
But aside from that, does 2dtk perform any kind of automatic geometry reduction? If I'm understanding how Unity works correctly my entire level only needs to be a single quad with my tile textures mapped on to it. I'm guessing a single quad is better than 12,500 or so. <- this is wrong, there isn't any way to do an entire level as one quad. Also 12k quads won't be bad. tk2d splits stuff up into partitions (default size 32x32, with a quad on each tile the max mesh size will be 2k tris.
I presume the partitioning system is there so you don't get the problem of 1 huge mesh that is always in camera and therefore always being rendered, correct? <- Yup. Ultimately if you run into perf issues it will be wise to profile with different partition sizes, but that is a non-destructive operation so there is room to experiment later.
There isn't much else with the tile map, just that creating and optimising poly / mesh colliders is the slowest part of the whole process. If you want to modify tiles at runtime keep that in mind, it will most certainly be more optimal for you to create and manage your own colliders. Also, don't ignore the flexibility static sprite batchers can give you, its useful to keep that in your arsenal for if or when you need it.