In the 32-bit versions your virtual address space is 4GB total; 2GB for User space, and 2GB for System. When you take 3GB for the User space, you only leave 1GB for the System space. This means it's twice as easy to exhaust the System address space, so you may run into kernel-level driver problems (things like disk controllers and other I/O).
I found this excellent article on TechNet that explains some of the pitfalls: "Memory Management - Demystifying /3GB"...
Here's an applicable blurb:
Remember that we only have a 4GB total address space to work with. If
we have to allocate an additional 1GB of this address space to the
user-mode space, then the System space is cut in half. Drivers, Heap,
Paged & NonPaged Memory all have only half the resources to work with
now. However, because of the way memory mapping works, cutting the
kernel space in half does a lot more than just reducing the address
space. Many of the structures within the kernel virtual memory space
are cut back by far more than 50%. For example, we took a Windows
Server 2003 Enterprise R2 machine with 1GB of RAM installed and
compared some values with and without the /3GB switch enabled.
Default OS Build:
Free System PTE's: 251,980 (1,007,920 kb)
NonPaged Pool Max: 206,848 kb
With /3GB enabled:
Free System PTE's: 34,884 (139,536 kb)
NonPaged Pool Max: 129,312 kb
As you can see, the Free System PTE's drops by over 200,000. Keep in
mind that this is only a test server that isn't under any sort of
load. A machine under medium to heavy load could quite easily run out
of free PTE's - meaning that the system can no longer map system pages
such as I/O space, kernel stacks and memory descriptor lists. In
addition, look at NonPaged Pool after the /3GB parameter is enabled.