My non-expert understanding,
Jailbird is basically right about why they dropped 16 bit support along with simplifying things a lot.
The compiler is the simple part, along with the linker (wlink fork is 64 bit), the assembly in the kernel is the hard part, it would need rewriting, which even IBM didn't touch.
Similar with most device drivers. Even the 32 bit will make assumptions about the memory being 32 bit. Windows had the same problem.
As Andreas said, there are device drivers, various parts of the main API and actually cmd.exe along with most of the traditional command line programs. They can be replaced.
Then everything would need rebuilding to be 64 bit. Likely even with source there would be hurdles, 32 bit assumptions. You could have a set of 32 bit libraries and such and run as 32 on 64 bit (forget the proper name).
We're missing source and a few skilled kernel people to even start, besides IBM might not allow it.
PAE seems a more possible course, but the kernel needs to support it, not simple. The low/high shared memory model we have might complicate things as well. Even when working, it seems there'd have to be some shared memory taking up that 4GB address space. Still even to give programs separate 2GB address pools would help.
It's manpower, IBM took years to port OS/2 to PowerPC (32bit), with lots of money and manpower. And they had the source and access to some of the people who wrote it.