Presumably because the current running workload doesn't need more than it reserved.
Virtual address space isn't a system parameter -- it is a measure of the virtual size of all the user processes across the entire system.
For a very simple example, let's say we have 3 processes running in total.
Process A uses: 5 Mb for Text, 15 Mb for Data, 2 Mb for Stack, 30 Mb for Shared data (which is shared with B, but not with C). All counts are Virtual, not physical (i.e. they represent the total size from malloc()/shmget()/mmap() [or just the system setting things up like Stack]).
Process B uses: 3 Mb for Text, 25 Mb for Data, 1 Mb for Stack, 30 Mb for shared with A, 10 Mb for shared with C.
Process C uses: 10 Mb for Text, 200 Mb for Data, 2 Mb for Stack, 10 Mb for shared (with B).
The total virtual address space in use is the virtual size of A (52Mb) plus B (69Mb) plus C (222Mb) minus the duplicates from cross-process sharing (the 30 Mb we counted in B that was counted in A, the 10 Mb we counted in C that was in B -- so 40Mb) or 303Mb.
Swap is required to back all virtual objects which are not backed by other means (which almost always just means "not backed by a File"). So in the above example [assuming the Shared objects are anonymous memory and not shared file mmap for simplicity], we can remove the Text objects from the total.
So our expectation is that the virtual space for each process which needs to be backed by swap is:
A: 15 (Data) + 2 (Stack) + 30 (Shared)
B: 25 (Data) + 1 (Stack) + 30 + 10 (Shared)
C: 200 (Data) + 2 (Stack) + 10 (Shared)
Again removing duplicates -- we see that the expected total swap consumption of the system would be:
15 (Data A) + 25 (Data B) + 200 (Data C) + 2 (Stack A) + 1 (Stack B) + 2 (Stack C) + 30 (Shared A/B) + 10 (Shared B/C) = 285Mb.
This is the virtual address space consumption of the System. (Well, there's some interaction with the kernel allocations -- but I'm trying to keep this simple for explanatory purposes...)
The total virtual address space available (for non-file backed objects) is the Total AVAIL on the swap line.
Whether that is Reserved or Used depends on if _physical_ memory got low enough such that the system had to page out memory. [Your output showing multiple Gb USED suggests there was memory pressure on this box in the past at least.] There isn't more Reserved here because no process needs more. If one of these three processes requests more virtual address space (through malloc or other such methods), the corresponding swap reservation request is made at that time, increasing the amount reserved.
By the way, while it hasn't been updated in some time (the tunable statements are very stale for one thing) -- you may find reading the Memory Management white paper illuminating for the basic concepts of HP-UX virtual memory management:
http://docs.hp.com/en/1218/mem_mgt.html
