obviously, it's not my choice - poweroftwo is the one developing this, but just look a the default FlightGear hardware requirements, then look at the suggested Rembrandt minimums - and now look at osgEarth doing tons of background processing and requiring a fair amount of additional RAM, at some point using a 32bit system simply no longer makes sense technically, even if it's just due to RAM requirements. We've seen reports by some 32 bit users here who've been getting segfaults because they were running out of memory in certain cirumstances.
Thus, frankly, maintaining support for 32 bit Windows is definitely do-able, but not necessarily such a good idea, we don't have any good way to track RAM usage per subsystem currently - and we're seeing enough segfaults/crashes as is. Expecting 3.0 users to be using a modern 64 bit OS and having hardware matching the requirements simply makes sense, and requires less effort than specifically supporting 32 bit platforms.
That being said, nobody is stopping you from building FlightGear from source yourself - so that you can build your own binaries, including support for 32 bit Windows.
I haven't looked at the code with 32/64 bit portability in mind, but I don't think the code itself does have any real/tough 64 bit requirements, it's just that the windows binary was compiled for 64 bit.
I just don't think that we should be providing such binaries, because we cannot easily provide the corresponding degree of end-user support.
Just look at the number of postings here from people wanting to run pre-OSG versions like 1.9 still
According to some recent discussions, FG versions post 3.0 will probably have more stringent hardware requirements, e.g. support for non FBO hardware (very old Intel GMA cards) may be explicitly dropped/discontinued. And the minimum screen resolution will be 1024x768 due to GUI restrictions.
There's also been talk about requiring a more recent OpenGL/GLSL version so that OSG can do certain optimizations automatically (=better framerates). And like I said, requiring 64 bit support makes sense due to increasing memory requirements.
None of that should stop people from building custom FG versions from source, it's well documented and we're here to help you out - and it's also the first step towards contributing to the C++ code, which is why it's a good idea for the project to teach people how to build FG from source