In short if you have relative low requirements (smallish database, the amount of transactions low) I would not bother setting up distinct table spaces for different page sizes. However there is a performance and space requirement related problem that will escalate if your database is large or your amount of transactions rises.
DB2 can save in maximum constant amount of rows in one page (source):
A table with a row length of 12 bytes
placed in a table space with 32K page
size utilizes only about 10% of each
page, which is calculated as (255 rows
* 12 bytes) + 91 bytes of overhead) / 32k page size = ~10%. This is only a
consideration if the table is large,
which means the wasted space is
significant. It also makes I/O and
buffering less efficient, because the
actual useful content of each page is
small.
There won't probably be noticeable difference in terms of performance if the database is small enough to fit completely into your bufferpools. Also if the database is small you won't probably notice a few extra gigabytes of spent space.
What you could optimize (probably what the IBM thought) is that you can set tablespaces on different IO devices, and also optimize bufferpools for exact use cases. Using the same bufferpool for all of your tables can lead for instance into some secondary function (for instance some janitor task in applications) flushing the most commonly needed data often out of the bufferpools. Putting for instance things like temporary tables into different tablespaces and bufferpools you can control what your valuable memory is used for. However as said earlier, these things start mattering only after certain point.
