If you've looked at the tutorial article in my signature and run the few tests, you'll be able to verify that mod_rewriting is enabled and functioning correctly.

Your page does load with the redirection made by hand.

That implies that mod_rewrite is not working OR you have something else in your ROOT directory (blog.php there) OR other code is conflicting with your code. You need to show your entire .htaccess for me to see about conflicts.

Using the / as the first character in the redirection tells Apache to look in the SERVER root directory for a match before looking in your DocumentRoot (root of the domain). Since your .htaccess is in your DocumentRoot, there is no need for the / and, thus, no need to confuse Apache about your intent.

I have major concerns regarding the server abuse contained within your .htaccess (it's not my problem, just things I need to point out to you as well as other members).

# Apache configuration file
# httpd.apache.org/docs/2.2/mod/quickreference.html
# ----------------------------------------------------------------------
# Webfont access
# ----------------------------------------------------------------------
# Allow access from all domains for webfonts.
# Alternatively you could only whitelist your
# subdomains like "sub.domain.com".
<FilesMatch "\\.(ttf|otf|eot|woff|font.css)$">
<IfModule mod_headers.c>
Header set Access-Control-Allow-Origin "*"
</IfModule>
</FilesMatch>
<font color='"#0000FF"'>[rant #4][indent]The definition of an idiot is someone who repeatedly does the same thing expecting a different result. Asking Apache to confirm the existence of ANY module with an <IfModule> ... </IfModule> wrapper is the same thing in the webmaster world. DON'T BE AN IDIOT! If you don't know whether a module is enabled, run the test ONCE then REMOVE the wrapper as it is EXTREMELY wasteful of Apache's resources (and should NEVER be allowed on a shared server).[/indent][/rant 4]
Compounding matters, you make several <IfModule> tests throughout your .htaccess and each one must be tested for every pass through your .htaccess (use a log level of 9 to see how many passes you make for each request).
If you have control over your server, move the <IfModule> and other core directives into the server's httpd.conf or httpd-vhosts.conf files where they'll be read ONCE. If you don't have server control, ask your host for help as it will ease the abuse of their server so they should be happy to help.</font>
# ----------------------------------------------------------------------
# Proper MIME type for all files
# ----------------------------------------------------------------------
# Audio
AddType audio/ogg oga ogg
AddType audio/mp4 m4a
# Video
AddType video/ogg ogv
AddType video/mp4 mp4 m4v
AddType video/webm webm
# Proper svg serving. Required for svg webfonts on iPad
# twitter.com/FontSquirrel/status/14855840545
AddType image/svg+xml svg svgz
AddEncoding gzip svgz
# Webfonts
AddType application/vnd.ms-fontobject eot
AddType font/truetype ttf
AddType font/opentype otf
AddType application/x-font-woff woff
# Assorted types
AddType image/x-icon ico
AddType image/webp webp
AddType text/cache-manifest appcache manifest
AddType text/x-component htc
AddType application/x-chrome-extension crx
AddType application/x-xpinstall xpi
AddType application/octet-stream safariextz
AddType text/x-vcard vcf
# ----------------------------------------------------------------------
# ETag removal
# ----------------------------------------------------------------------
# FileETag None is not enough for every server.
<IfModule mod_headers.c>
Header unset ETag
</IfModule>
# Since we're sending far-future expires, we don't need ETags for
# static content.
# developer.yahoo.com/performance/rules.html#etags
FileETag None
Options +FollowSymLinks
RewriteEngine On
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.+)/$ /$1 [R=301,L]
<font color='"#FF0000"'>RewriteCond %{SCRIPT_FILENAME} !-d
RewriteCond %{SCRIPT_FILENAME} !-f</font>
[indent]Is this for u/{something}? Why did you use {SCRIPT_FILENAME}?[/indent]
RewriteRule ^u/(.*)$ <font color='"#FF0000"'>/</font>profile.php?u=$1 [QSA,L]
RewriteRule ^c/(.*)$ <font color='"#FF0000"'>/</font>company.php?c=$1 [QSA,L]
RewriteRule ^blog/([0-9]+)/(.*)$ <font color='"#FF0000"'>/</font>blog.php?post_id=$1&title=$2 [<font color='"#808080"'>R=301,</font>L]
[indent]Good - but only use for your testing then remove![/indent]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^([^\\.]+)$ $1.php [NC,L]
[indent]1. I would have tested whether the .php extension IS a file rather than the current request not a file
2. No need to escape . in a character range definition
3. I would "reverse" the \\ and exclude /
4. The No Case flag is intended for the case INsensitive {HTTP_HOST}, not {REQUEST_URI} which IS case sensitive. Besides, both cases (and the kitchen sink) are matched by your character range definition so this is useless here, anyway[/indent]
RewriteCond %{HTTP_HOST} ^www\\.(.*)$ [NC]
RewriteRule ^(.*)$ http://%1/$1 [R=301,L]
[indent]I wouldn't have bothered Apache to copy the {REQUEST_URI} string again for the redirection and merely use RewriteRule .? http://%1%{REQUEST_URI} [R=301,L].[/indent]
RewriteCond %{THE_REQUEST} ^[A-Z]{3,9}\\ /index\\.php\\ HTTP/
RewriteRule ^index\\.php$ http://pitchbig.com/ [R=301,L]
[indent]You were smart enough not to use the end anchor so why did you use the start anchor? The format of {THE_REQUEST} is "GET /index.html HTTP/1.1" and it looks like all you needed to match was the index.php ... which is exactly what the associated RewriteRule does.[/indent]
RewriteRule (.*)\\.xml(.*) $1.php$2 [nocase]
[indent]Possibly nothing before or after .xml? That doesn't make any sense (to me - just like the nocase).[/indent]
ErrorDocument 404 /404.php

Okay, with all my comments about your coding, I didn't see anything before your blog rule which would prevent it from matching nor anything after which would redirect from blog.php.

Suggestions:

Clean-up and move core directives to the server/vhost configuration files

Reorder to move all remaining core directives above mod_rewrite

Reorder the mod_rewrite to handle site-wide changes (e.g., remove www and remove / from non-directory requests) first, then specifics (like the blog) then general redirections

If the blog keeps failing, move it around in the list of mod_rewrite redirections

If you have specific questions, go ahead! The best way to learn is to get semi-educated through reading then ask question about things which weren't clear (that also helps me to discover where the tutorial needs some editing).

LAMP server, eh? Great! I won't host on a WAMP server but that's what I'm stuck with as a test server. Nearly identical except that WinDoze doesn't provide all the services a 'nix server does.

IMHO, it's not interesting, it's MANDATORY! Okay, if it's your server, mandatory is wrong but doing "silly things" (of the type I was whining about) on a shared server should get you barred.

Okay, the leading / wasn't required anyway but the fact that there is no change means that you are getting the blog.php in the DocumentRoot (not the server's root).

{SCRIPT_FILENAME}: Typically, %{REQUEST_FILENAME} is used (as you have done) and this was only attached to the one RewriteRule (which followed). That was highly unusual.

Then, the Apache Foundation says:

http://httpd.apache.org/docs/2.2/mod/mod_rewrite.html said:

The variables SCRIPT_FILENAME and REQUEST_FILENAME contain the same value - the value of the filename field of the internal request_rec structure of the Apache server. The first name is the commonly known CGI variable name while the second is the appropriate counterpart of REQUEST_URI (which contains the value of the uri field of request_rec).

unemployment said:

I'm aware it is. It just doesn't grab my attention as much as front-end development.

Well, that's too true! The first blog would have requested blog.php but without creating the query string. If blog.php is smart enough to read the URI, however, it might have resolved the problem even with the (IMHO, HATED) MultiViews was enabled.