QB64 because it is the closest to QB.
This is a stupid question, because if you prefer QB then you are also going to prefer QB64 which is QB with knobs on, so the vote should be between FB or QB64.
It would be interesting to put the same question every month to see if there is any shift in opinion. At the moment FB will be more popular than QB64 because it has more users, due to the fact that FB has been in existence for a much longer period. My reason for choosing QB64 is that its aim is to bring QB into the modern era. As Galleon put it, the aim is QB64 >= QB

I have just started to play around with FreeBASIC the only thing I can say is that it is odd how many basic compilers don't have tip-top IDE's (FreeBASIC does OK. but there isn't one for QB64). An IDE that had several compilers might be a good option maybe a comment line that defines which tools and compilers come up when you open the file. The other thing that I will say about QB64 is that the advertisements are annoying maybe instead of some guy in the advertisement they need more scantily clad women and the more documentation the better.

My favorite language is FreeBASIC, anyway I'll try to be objective:

QB:
Good
-It is THE original language: many attempts to build an improved, more modern version of it haven't decrease it's popularity (softwares like TurboBasic, PowerBasic, RapidQ, Visual Basic never replaced it)
-It has been used to write FreeBASIC (OK, actually it was written in VBDOS) and QB64
-It is a standard: users know exactly what they can have, and don't comply about a missing feature they need.
-It has an IDE with a contextual help and debug features that isn't available on other languages
-It produced very small executables
Bad
-It is commercial: buying it is very difficult, and download a copy is against the law (maybe Microsoft doesn't really care about it, but you can't sell programs made with an illegal version).
-It is DOS-only: to run it, on many system an emulator is needed
-It can use only limited resources (can't use full memory, higher resolutions, sounds...)
Conclusion:
Although QB language is still full of life, the QB compiler is obsolete. Some systems (like Vista) are slowly dropping DOS support, and 16-bit applications are every day less supported, so a new compiler is needed.
FB
Good
-Open source: if somebody needs a feature, he can add it (or at least try...). Also, it will be always supported as long as there is somebody interested in it
-It has an active support, so new features are constantly added, and bugs are promptly fixed
-It is multi platform: works under DOS, Windows and Linux, and many programs works with no changes.
-It allows the use of all system resources, because it can access the system API (or, under DOS, the interrupts)
-It can be used to write OS (see http://wiki.osdev.org/FreeBASIC and http://wiki.osdev.org/FreeBasic_Barebones)
-It has partial OOP support
-It supports advanced programming features, like scope, pointers, function overloading...
-It supports a QB-compatible mode
-It produces very fast executables
-It has threads, allowing true multitasking apps (at least in windows and Linux)
-It isn't one, but actually three programming languages (four, if you consider the 'deprecated'), so you can choose the language which best fit your coding style.
Bad
-It isn't 100% compatible with QB (i.e., it doesn't allow scalar and array with the same name)
-The OOP support is still incomplete, because it lacks inheritance and polymorphism
-The default dialect is a bit too C++ like (all variables need to be declared, there is no GOSUB...). To have a more BASIC-like language, the switch -lang fblite is required.
-It's an evolving compiler, so you can't be sure that a feature you use will not be changed in a future version.
Conclusion:
If you can imagine QB with the power of C, you are thinking of FreeBASIC: it brings programming to the next step, allowing almost all the features that QB programmers missed. Definitely a good choice for anybody who needs to leave Basic and switch to C++, but doesn't want to learn from start a new, hostile language.
QB64
Good
-It offers good QB compatibility. It even emulates the PC-speaker and the screen modes, in a way similar to DosBox.
-It works under Windows and Linux (while I'm writing, the Linux version isn't yet downloadable)
-It supports advanced features, like new types, multimedia commands, 2d enhanced graphics while keeping backward compatibility with old QB sources
-An IDE very similar to the original QB one is being developed.
Bad
-It's still incomplete
-It's slower than FB, and produces bigger executables
-Compiled programs need a bunch of DLL to work, so they can't be stand-alone
-There is no real console: the text mode is actually a graphic window (so copy&paste won't work on it)
-the BAS file is converted to C++, then compiled with GCC: in that way, compiling is very slow, and finding an error could be very hard.
-It use a sort of hack to supports new commands without broking compatibility, because new commands have to use an underscore prefix: commands like DIM A AS _BYTE are very ugly to see.
Conclusion
Calling QB64 a compiler is reductive: in fact, it's not intended to be a compiler for windows, but to allow porting of old sources under newer system, so it's a sort of half-way between a compiler and an emulator; QB, too, was not only a compiler, but also a full programming environment, and QB64 goal is to recreate the same environment.
We must not forget that, while FB is on the road from 2004, QB64 is much younger, and it grew in a short time: if it can keep the same grow rate, it could become something really interesting; think about BlitzBasic, a compiler intended to be compatible with an Amiga version, that became a powerful 3D programming language

QBASIC - This was my first real experience with programming. It taught me a great deal about writing programs, and it was as lot of fun, but over time I did get frustrated with its limitations in speed, memory and functionality. I still program in it occasionally, and I find the debugging features useful, but I often find I miss having an equivalent of Option Explicit. Sometimes I may switch code between QB and FB so I can take advantage of both.
FreeBASIC - This is generally my language of choice. It's much faster, has a lot more features, and a lot more power. I think by this stage I'm significantly more familiar with it than any other language. There's also a lot of great guys out there in the community, and they come out with some pretty cool stuff. Of course it may just be that I've come from a BASIC background, but I find FB is an easy language to express ideas in. Importantly though, it also gives me the speed I often need, which means I can spend more time on getting something working initially than having to worry about the efficiency of it. So it's easy to get working code up and running quickly. It's also fairly easy to go back into it and optimize it later, if necessary. FBC includes support for a profiler, which as an invaluable feature when trying to work out the bottlenecks. I also find FB good for writing quick programs, such as fairly non-trivial calculations, or parsing a set of numbers. I rattle off countless quick programs in FBIde - perhaps the majority of them, I don't even save anywhere. We get along just great, Quick Run and I...
QB64 - here's one to keep an eye on. I think when it's nearer completion, it will have a lot to teach us about ease-of-use. Designed to work like QBASIC in as many ways as possible, including the mimicking of much of its lower-level behavior, it should prove easy for a QB programmer to pick up, and many old QB programs should compile and run without any modification.
Having an SDL backend can make the resulting programs feel quite bulky, but it also makes it a lot easier for QB64 to implement a whole load of extended graphic and sound related capabilities, right out of the box. Having so many features intrinsic to the language, also gives a simple, "official", recommended way to do most things, which will appeal more to some people than seeking out an appropriate library and learning how to use it.
I worry sometimes about the difficulties it has of merging new features with uncompromising QB compatibility - for example, I'm not a fan of the system of prefixing new keywords with underscores to prevent them clashing with potential QB identifiers, but I think it'll be OK if they can come up with an alternative solution.
If QB64 gains a good userbase, then we'll hopefully see a lot of good-quality games coming from their direction.

I would not care to read comparisons as each has it's own merits. But FB and QB64 were children of QBASIC to begin with. So QB wins lol!

Why choose QB64?
...for a philosophy that says "100% compatibility with QBASIC" and "let's keep things BASIC"
...for saving QBASIC from becoming a language only emulators and obscure systems can run
...for preserving and extending existing QBASIC programs, and writing new ones
...for supporting an emulated 16-bit DOS conventional memory environment used intuitively when required
...for none of the memory/filename/etc. restrictions QBASIC suffered from
...for more data types including 10-byte floats, 64-bit integers, unsigned types and bit types
...for programs which run much faster than in QBASIC
...for multi platform porting without any code changes (Windows, Linux, Mac, and any other OS C++ code can be compiled on!)
...for a fixed, inbuilt set of powerful commands to cater for modern programming needs such as:
tcp/ip,wav,mp3,midi,jpg,bmp,png,gif,ttf,32bit color,alpha,gamepads,web-cams,video and much more...
...for fast, quick and easy development of impressive programs
Why wouldn't you choose QB64?
...because it has still got some important milestones to reach (which are rapidly being met)
Consider this: You're a QBASIC programmer looking at a program written in a QBASIC-like language, but don't understand the syntax and symbols you see... is it really QBASIC-like?
FB is not a QBASIC compatible language. It does have a "-lang qb" compiler option which provides a higher level of compatibility with QBASIC but at the cost of using a neutered, hacked version of the pure FB language which is a different language in its own right. I say this not to offend the FB developers, but to explain my strong feelings and rationale behind QB64's development. FB is a great programming language and will probably continue to be a greater, more powerful programming language than QB64 will ever become. Only a very small percentage of QBASIC programs actually run in FB, even with the "-lang qb" option, QB64's percentage is already at least twice as high. QB64 has been in development for less than one and a half years.
I know C++ but I love QBASIC.

I think that FreeBASIC, QB64, and QBASIC all have their strengths.
QBASIC's advantage is its IDE and debugging support. It's disadvantage is being limited by MS-DOS [1].
FreeBASIC is useful for running QBASIC programs on Linux because Qb64 does not work on it yet, as well as on Windows if smaller exe sizes or greater speed is desired. I use FreeBASIC on Linux but on Windows I usually use QBASIC.
QB64 is more compatible than FreeBASIC for running QBASIC programs, but it produces large exes that are slower than FreeBASIC ones. It runs on windows or on Linux with wine [2] . Qb64 is not done yet, so in the future, it will probably improve and be able to access "modern" OS features like FreeBASIC can.
[1] But 640K is still enough for Bill Gates.
[2] QB64 at the time of writing this article has a non-public build running on Linux.

I mainly say FB because I have extremely limited skill and experience in programming and I haven't used the other two. But FB is good for what me and my friend are trying to do. It's easy and efficient, it's really easy to debug as it is really organized and easy to read. None of those uber-curly-bracket attacks or those "semicolon replaces your period" things. The lack of "rules" when it comes to your coding makes FB easier for me, I can just think about the function and forget about the form, at least until I clean the code up. I usually use FB for simple graphics simulations and for creating simple mathematical simulations. FreeBASIC seems to work just fine, I have little trouble getting it to work. Another plus is the absence of the tedious preparatory code that you have to use in languages like C++ just to get the thing to work, a few lines in FB and I have a screen that displays my avatar, bingo. However, like I said, I haven't used any versions of Q-Basic so I can't really compare the three. But I can say I do like FB a lot. It is a very smooth and simple language, with a backbone of great power! Like the language of love, only without late night fights and baseball bats to the left headlight of your car.

I use FreeBASIC, for 2 reasons, one its 32bit were as QB is 16bit, meaning that QB wastes good CPU on anything better than a 286. The other reason is my main desktop runs Linux and FreeBASIC has a native Linux version. I might use QB64 if it get a Linux version someday.

Since I ported a hexgrid program to FreeBASIC from QB and saw the speed difference, I haven't been back to QB. The program needed minimal if any change to get it working in the FreeBASIC language (these days you might need to use the option -lang qb). FB helps to keep you using current coding practices, and is still being maintained/developed. FB is a powerful modern day language.

For most of my programming, I use FreeBASIC (version 0.20.0a). This has been true since they fixed my two "big" issues with FB back then, PCOPY working in SCREEN 0 and a cursor feature in Graphics mode. Since then, it became the language of choice. Simply because although I've had a computer upbringing that constantly involved being memory conscience of 8 bit and 16 bit computers, I guess I grew tired of these restraints. I still worry about these restraints and always try to keep my code optimized for speed and size for my bigger projects but it's nice to know I can tackle much bigger projects. For what I need, FB does the job fine and fast. I'm keeping up to date on OOP and how it works but I probably won't be using it until inheritance is implemented but I'm just keeping up to date so that i know how it all works by the time I need to use it :). In general, as a language to build application goes, FB is pretty good.
And for those new to FB, I'm a programmer that use to program in Pascal, a language where everything "absolutely everything" you use in your program must be declared (prototyped first). In FreeBASIC when I convert my QB code to FB's native language, the fact that I declare my variables (as if I was writing pascal code) seems to really shorten my workload of converting programs to FreeBASIC.
I am keeping a very close eye on QB64 however, I can see it's progressing (although more recently, I'm hoping to get more updates from Galleon (QB64's creator). Because it too promises to be a great language to use, maybe more so for those of us QB coders that really pushed low level access and such to the max back when QB was popular and used regularly. System calls, and such, to port that kind of code to FreeBASIC is one major undertaking, so perhaps QB64 might be a much better solution for porting projects that made excessive use of interrupts, BIOS calls, assembly language and the likes. Although I don't exactly like the underscore approach for language extensions, QB Compatibility is very important to QB64 and as such, in the end, a very different compiler is probably going to result from it. Something some QB users might feel much better using than the way FreeBASIC does things. I can't wait to see where it all goes for both QB64 and FreeBASIC.