One thing that doesn't make sense to me about the app gap is that a lot of apps that are not available for WP are available for Windows as programs.
Do you mean as traditional .EXE style programs? Those are very different from app store apps, and even more different from phone store apps. Most desktop apps need a substantial rewrite to become a WinRT tablet app. Most Windows applications use an API called Win32 - very few use the newer WPF API. The API for Windows Store apps is loosely related to WPF but there are a lot of apparently gratuitous differences and gaping holes (compared with Win32 and the .Net BCL) that I think are due to fact that the Windows Store API was done by the OS group instead of the development tools group. The incompatibilities are aggravating; the insistence on async/await everywhere makes development and debugging more time-consuming, and the missing API capabilities (many of which are missing
on purpose) means that comparable store apps simply cannot be written, or doing so will require huge amounts of workarounds. If the market were huge then this might be worth the effort, but it's not, and what market there is doesn't appear to be purchasing store apps (There are theoretically nearly a hundred million Win8 machines out there, but you don't hear of anybody getting rich off of store apps the way you did in the early iPhone days).
It would seem second nature to me as a programmer to make a Windows app if I make a program as they both can run on the same system so why isn't this the case?
Because this isn't really the case, and where it is the case it isn't economically useful.
Windows store apps can only run on Windows 8 or 8.1, x86 or ARM; phone store apps that will only run on windows phone 8 or 8.1 (WP7 only if you're really willing to gimp your app). Windows store apps cannot run on Windows XP, Vista, or 7. On the other hand traditional Windows applications can run on Windows XP, Windows Vista, Windows 7, Windows 8, and Windows 8.1 on x86. Notice the near complete overlap between the two - the only platforms traditional applications are missing relative to store apps are Windows RT ARM devices; and this wouldn't be so much the case had Microsoft not locked down Windows RT. It's actually a full-blown windows complete with the Win32 API's, its just that the OS has a registry setting that prevents traditional applications from being installed. An ARM version of the application would have to be generated with a cross-compiler but that's old technology - I was doing Windows development on a DEC Alpha Windows NT machine in the mid 90's.
Anyway, as a developer I can write a store app which is likely to be a complete rewrite in order to gain access to the small market for Windows RT tablets (remember, all x86 machines that can run Store apps can also run my existing traditional application), or I can do that complete rewrite to build an iOS app that gets me access to the iPhone or iPad market. This is really a no-brainer for a developer with bills to pay.
Unifying the Phone and RT API's and stores is a good step; there are a lot more windows phones out there than there are RT tablets, so this makes the incremental market for an RT app much larger. They also
really need to figure out a way to let Windows Store apps run on the desktop, and run on older OS's (at least Win7, and preferably Vista as well). This makes it more viable to write (and support) one app for all windows devices, both traditional desktop, tablets, and phones.