First, up front, I don't know what the presumed attacker is trying to accomplish. Maybe there's a PHP script or PHP version out there vulnerable to some strange session ID attack, I dunno. You probably have nothing to worry about, though.
Your server behaved exactly as expected. 200 is the expected code in that particular situation because of how Apache interprets the URL being passed to it.
First, http://allrequestsallowed.com is treated like the more usual 'Host:' header (note that I don't think this is specified in the RFC and other servers may not interpret it this way I was wrong, this is specified in RFC 2616 in section 5.1.2, even though clients rarely seem to use that form. Excuse me, I need to go fix an HTTP server implementation I wrote a while back...).
Now, presumably you don't have a site named 'allrequestsallowed.com'. So what happens when Apache gets a Host: header (or equivalent) for a hostname it doesn't recognize? It picks the first virtual host as the default. This is well-defined and documented behavior for Apache. So whatever your first virtual host is (or just the main server configuration if there aren't any vhosts) takes over, no matter what it's named.
Now, the rest of the URL given consists of two parts -- the path, /, and a GET parameter (the ?PHPSESSID... bit).
Now, the path / should be present on pretty much every web server out there. In most cases, it maps to something like index.html or perhaps an index.php script, though you can override any of this of course.
If it maps to a static HTML file, absolutely nothing unusual happens -- the contents of the file are returned, and that's that, the parameter is simply ignored. (Assuming you don't have certain advanced configuration directives set, and you almost certainly don't.)
On the other hand, if it's a script of some sort, that PHPSESSID variable will get passed to the script. If the script actually uses that variable (in this particular case, only PHP scripts using PHP's built-in session handling are likely to), its behavior will depend on the contents.
In all likelihood, however, even if your / happens to map to a PHP script using sessions, nothing remarkable will happen. The session ID probably won't exist anyway, and will either be ignored, or the script will show an error.
In the unlikely case that the session ID does exist, well, the attacker could conceivably hijack someone else's session. That would be bad, but it's not really a security hole in itself -- the hole would be wherever the attacker got the session ID information from (sniffing a wireless network is a good candidate if you're not using HTTPS). They wouldn't actually be able to do anything that the user whose session it originally was couldn't do.
Edit: Additionally, the '%5C' inside the SESSIONID maps to a backslash character. This seems to be a test for directory traversal attacks on windows hosts.
curl -v http://allrequestsallowed.com/?PHPSESSID=5gh6ncjh00043YVMWTW_B%5CFAP -x www.example.com:80. The default config seems to return a "Welcome to nginx" page with no meaningful content, on our ubuntu system. So it's a 200 response, but it's a simple catch-all page -- we're not actually proxying the request elsewhere or anything like that.