All sketches are stored in Processing's temp directory until they are saved, after which they are placed in the sketchbook folder ( USER_HOME\Documents\Processing). You can change the sketchbook folder location from the preferences window ( File > Preferences). The UDP library should go in the "libraries" folder, which should be inside the sketchbook folder.

" Processing believes my sketches sketch folders is [...]"
That's the path it uses for unsaved sketches.

" I want all processing folder sketches to be C:\Program Files (x86)\Processing\sketches"
Very bad idea. Why put sketches, which are user files, in this folder protected by the system (particularly in Windows 7) which shows annoying messages each time we try to put a file there?

I put my sketches in a specific, self made path (like H:\Dev\Processing\), lot of users just put them in path like D:\Users\Pat's Machine\Documents\Processing\, and so on.

Have you seen the article http://wiki.processing.org/w/How_to_Install_a_Contributed_Library

I find your statement "Very bad idea" a bit disturbing.  Here are 5 comments that support my position.

1) As operating systems have changed, their vendors have evolved what they think the end user wants to do with his files.  A change in their views forces a change on our part.  This has repeatedly occurred at has operating systems have evolved. I doubt anyone on this forum believes that operating systems have stopped evolving.
2) Security of data is becoming much more important.  Current commercial philosophy is that all data including configuration files are treated as private intellectual property that must be protected from outside and inside thief and alteration.  To this extent, all such data should be located on a secure spindle (real or virtual) with associated encryption.  Having data in two different locations makes this difficult.
3) Backup of data is also important.  If the data is located in a single directory location, backup can be as simple as copy to a memory stick, though this kind of backup certainly runs counter to concept (2).
4) Distribution of product.  If a production (think open source for the moment) needs to be distributed and their may be several different operating systems that are targets for distribution, a single directory structure is an easier entity to distribute even if zipped.  If data must be placed in multiple district locations, some sort of install package is required requiring a more difficult installation preparation not to mention a more complex testing and validation.
5) Complexity leads to chaos.  One of the abiding principles is KISS - keep it simple stupid.  Though the initial installation of "Processing" was simple, the development of the installer was not as simple as a simple zipped directory which would work equally as well.

Finally, I looked up your profile.  I too am a developer but I started my career in 1968.  The current Arduino system (Mega) that I am testing using "Processing", has more memory that computers I started with back then.

I am not sure how your points counter my remark...
1) enforces my point: Windows has evolved from allowing to do anything in Program Files to restricting a lot writing there, forcing some softwares (like Google Chrome browser) to install in the user files, which is bad (for backup reasons, among others). Personally, I got at work a PC where my working account is non-admin, and it is a punishment (even if I have free access to an admin account) with all the restrictions unbalanced by some sane behavior (Linux sudo doesn't ask password for a while, at least!), so I installed all my small software (freewares, open source) in a separate folder of my own.
2) There is no, or there should not be data in Program Files, except perhaps data coming with the installation of the software, that is easy to re-install (or should be).
3) Indeed. That's why data should be in the Users side of the computer, not mixed with software that doesn't need backup. And, well, I have a different idea of organizing my hard disk, separating my own data from downloaded / installed data. For quick re-installation of a whole disk, there are disk image softwares.
4) I don't see the point. You mix up your data with the data from Processing? You don't distribute your data along this one, are you?
5) Again, this seems unrelated with the location of your sketch folder.

I have several versions of Processing on my hard disk (although generally I keep only a pair of them, currently 1.5.1 and 2.0a). Which folder to choose? Idem for Eclipse, for example: on each upgrade, I have a transition period where I keep the older version beside the new one. If I had to move my workspace location each time, I would be in trouble.

Most of the time, I reply here to people with little to no experience of programming (sometime even of computing in general!), so I give advices without prejudice on their level of experience, remaining at a rather low level.
If you believe you do the right thing, that mixing third party software and your data is a good idea, go ahead, who I am to prevent you from doing that, since you know what you do and it suits you. But I still won't advice to do so to other people! And the first point, that Windows might interfere with the writing of data in Program Files, still stands. Modern Windows tend to see this area as almost read-only (except for acknowledged installers), that's why the practice of writing .ini files at the same location of the .exe has been mostly abandoned.

Your point of view is interesting, but I rarely, if ever, saw people advising to keep software and data mixed together.
Or perhaps we are just misunderstanding each other (as you can see from my style of writing, English is not my mother tongue, so some subtleties can escape me).