One VBO per object is one valid way of doing it, if you don't have too many different object types, if you can sort by object type before drawing, and if you implement some state-change filtering on glBindBuffer. A couple of 10s of buffer object changes per-frame isn't going to significantly show up on any performance graph (you'll be more likely to bottleneck on transforms and fillrate), a couple of 100s is more likely to be problematical.
For sprites however, and as you've deduced, it's not a good idea. 4 vertices per buffer isn't a great ratio, and if you're animating as well, you may be even needing to fill all of these buffers dynamically each frame too. That's not the kind of use case that buffer objects were designed for.
That's not to say that you shouldn't use buffer objects at all for drawing sprites, just that drawing them is a little bit more complex than "just use a VBO". You need to implement some buffer object streaming in order to do this and make it efficient. The link I've provided gives a good overview of the concept, several implementation possibilities, and useful links for further reading.
If this sounds like it's going to be overkill for what you want to do, then another alternative is to just not use VBOs at all. Client-side vertex arrays are one option, but another is just using glBegin/glEnd. If you don't absolutely have to use VBOs then the latter can be viable, and you should definitely benchmark it and consider it as a possibility. You may read horrible things about it elsewhere, but remember - Quake used it in 1996, it didn't suffer from horrible performance problems on account of using it, and it can easily hit almost 1000fps on modern hardware. So - if vertex counts are low enough to begin with, if fillrate is going to be a bigger bottleneck anyway (as will be the case with sprites), and if you can already hit your performance target without needing to optimize further, glBegin/glEnd can be perfectly OK to use.