If it had been two PBO with one texture bound each
First mistake: textures are not bound to PBOs or vice-versa. A PBO is just a buffer object that you use to transfer data to a texture in place of a client memory pointer.
Second, the reason to use two buffer objects is to gain maximum performance. There are 2 steps in streaming data: getting the data from wherever it is coming from (reading from disk etc), and the DMA transfer of that data to the texture. You use one buffer object as the destination of a read (step 1), while a second buffer object is being used as the source for a write (step 2). It gives maximum performance, at the cost of memory.
To do what you’re suggesting would be no different from using one PBO for each texture.
In any real application, would you not have at least two textures as well as two PBO?
Well, that depends.
The two PBOs is for a specific case of streaming: you need to update the texture every frame. If you’re only streaming data “infrequently”, if your data-set is simply larger than can fit into video memory, then you are not guaranteed to be streaming data constantly. You also generally have some textures that aren’t currently being used, which are the destination textures for streaming in a new section of data.
With this kind of streaming, you generally give yourself several seconds of latency. That is, you say “I need the data for block X” long before you actually intend to start using it. In this case, you may use one or two PBOs for multiple textures.
This kind of streaming is far more prevelant than the kind where you need to update a texture every frame. That kind of streaming is typically movie rendering. And you’re generally only rendering one movie at a time, so it’s not a problem.