I'm probably not smart enough to find bugs or break your script, but I can see things that make me nervous.

I've heard (and I usually agree) that it's always better to define what you want to allow, rather than define what you want to disallow. You're disallowing periods and to some extent slashes, but you're allowing nearly anything else.

In reality you'd want a filename to match a pattern like /^[A-Za-z0-9][A-Za-z0-9.]*$/. (Or modify it to allow slashes, but I wouldn't even allow them at all, personally.) Anything that doesn't match your regex should be rejected immediately. I passed your script a filename like #$%%*#!!%#^ and nothing bad happened, but still it accepted it as a valid filename all the way to the point where it was testing the filesystem for its existence. That's probably not good. I was looking for ways to URL-escape a "." character, and couldn't find any that survived your script, but if there are some, it would defeat your script also.

People can also start passing arbitrary binary data in via POST. I'm always scared someone's going to send me a 50MB URL and it's going to overflow and start doing horrible things.

You're also disclosing to the user the names of all your files. There's no reason the user needs to know this. If your files are in some path not in DOCUMENT_ROOT, you're exposing what your server's file structure looks like.

One extremely simple way I know of to define what you want to allow is to make a lookup table. The user specifies a key into your lookup table. You just have to reject invalid keys.

PHP Code:
<?php

$allowed_includes = array( 
    'file1' => 'some_file.php', 
    'file2' => 'some_other_file.php', 
    'file3' => '../../this/is/still/safe',
    'file3' => '/home/user/.secret/.....as/is/this/if/you/really/want/to',
    'file4' => 'and/you/can/hide/the/real/filenames/from/the/user'
);

if( array_key_exists($_REQUEST['path'], $allowed_includes) ) {
    include($allowed_includes[ $_REQUEST['path'] ]);
} else {
    print "No.";
}

?>
Here the single thing you're doing with user input is using it as an index into an array. I don't know of any security issues with that. I don't think you even have to escape the user input or manipulate in any way. If it does turn out there's something insecure with indexing an array in this way, you can very simply drop in another data structure in place of the array. The bad thing is you need to define the array manually and don't allow the user to specify entirely arbitrary filenames. (This may or may not be a good thing actually, depending on your point of view.) But you could get around that by having all your includes in a single directory and globbing it for filenames at runtime, and assigning each a key based on a cleaned version of the filename or an incrementing key value or whatever.

This way you also aren't required to forbid using .'s in the pathnames or any other limitation. You are controlling the file access entirely yourself so it's safe to include any file you want on your system in this way. (Depending on what you're doing with it once you include it, obviously.)

Again I may be entirely wrong. I don't know as much about this as I'd like.