The number of LUNs you use will depend on what's sitting behind that LUN (ie, how the LUN is defined by the storage admin), with the (normal) objective being to insure you're getting good/fast performance on your dataserver disk IOs.
I'd start with taking a close look at your sp_sysmon numbers; you want to make sure you haven't maxed out the number of outstanding disk IOs at the engine and/or server level. The default dataserver configuration for disk IO management is typically too small (eg, max IOs per device=256) for today's systems, with the net result that you're putting an artificial bottleneck on how many disk IOs the dataserver can handle at any one time. I typically make sure max IOs per server = 2billion, with max IOs per engine = 5K-30K (depending on what the underlying system can handle; also requires that you configure the dataserver to manage the larger volume of IOs - see ulimit). The primary objective is to let the dataserver push as many disk IOs at the disk subsystem as possible (ie, push any bottlenecks down to the disk subsystem), then have the system/storage admins see what (if anything) they can do to address any bottlenecks at the disk subsystem level.
Once you've eliminated any (artificial) bottlenecks at the dataserver level you'll want to get your storage and system admins involved. You'll want them to monitor your LUN's IO performance (reads and writes) over a 1-3 day period (you want to make sure they are monitoring 'normal' day-to-day user activity as well as some of your batch cycles => database dumps, update stats, dbccdb operations, etc).
On systems I've managed recently I've typically seen disk IO service times of 2-5ms for 'fast' disk technology, and disk IO service times <1ms for SSD-based technology ... ymmv.