a) bypassable (by simply not sending a session cookie), and
b) exploitable to DOS your server (PHP processes are single-threaded so sleep() is basically just a blocking call) - I could just bombard your server with a bunch of login requests to eat up all of the connection slots that end up sleeping for a very long time. You can't serve legit traffic when all of your PHP workers are off sleeping for six hours.
There's not a huge amount to be gained by building a super sophisticated anti-spam or anti-brute-force system until it's likely that someone will actually write an attack specifically for this software, and seeing as I built it mostly for my own use, anyone who did that is probably just trying to do damage to me (for whatever reason).
You're using the very fast md5/sha1 (why both?) functions for password hashing. PHP has bcrypt support; why not use it instead? That a) accomplishes the goal of making brute-force untenable, and b) further protects your users' passwords in case you ever accidentally introduce a SQL injection (which, if you continue to work on this project, you probably eventually will; no personal offense - that's a big part of why more comprehensive frameworks that try to abstract away from raw SQL exist. Human make mistakes, especially in 6000-line superfiles ;)
Edit: Also, your password updates (and other POST-ish operations, except commenting) don't have any kind of CSRF protection, so I could reset your password if I can get you to interact with a page where I've set up some "proof of concept" of something you might find interesting, with a form to post to yoursite.com/?p=savesettings&password=0wned, at which point I just log in and take admin control of the site. Since you don't ask for a username on login, such an attack would be extremely trivial.
(As another commenter mentioned, it's easy to discover that much of the 'bloat' is actually stuff you want!)