This is basically a full re-write of the answer as of Feb 2020, with significantly more detail.
EncFS is reliably safe under the kinds of circumstances and threat models that most casual users would expect to encounter, particularly with document-synchronization services like Dropbox. More specifically, it works great when your expectation is something along the lines of: "an attacker cannot read my files."
But it doesn't do so hot when you start chaining more complex assumptions on top of it. This typically happens when the directory you're protecting is used in ways thought up by someone else, like the profile directory of a browser, the data storage of some automation pipeline, or the home directories for all the users in a company. If your expectation is more vague and all-encompassing, like: "attackers will all be thwarted because the directory is encrypted," then this isn't the tool for you.
To make a well-reasoned choice, it helps to understand what trade-offs you're making. So here's what an attacker can do, and under what conditions they can do it.
Metadata
EncFS stores exactly one encrypted file per unencrypted file, and with the same sort of directory structure, the same modification times, and similar file sizes (and filename sizes). So the attacker will know basically all of the metadata about your files. This is an intentional security trade-off, so if this sounds dangerous then EncFS is not for you. You can infer a lot from just dates, sizes, and directory structure, particularly if you're watching over time (see below). This could be all the information the attacker needs in order to deduce certain kinds of behavior. If that matters to you, then it's an example of relying on EncFS to protect more than just the contents of the files, and means you need a different tool.
Of particular note, EncFS supports sparse files, which means that long (very long) runs of zeros aren't encrypted. Any of these empty chunks are readily identifiable in the encrypted store. This is another intentional security trade-off; it can save you a lot of storage space, but at the expense of revealing a bit more about these special kinds of files than you may be comfortable with.
Metadata History
If the attacker can see the changes over time, then they get even more information. They can see which files change and how often, whether the changes influence the file size, and so on. In some cases they can even tell roughly which part of the file was changed.
Dropbox stores some amount of file history (30 days or more, depending on your subscription and settings), which makes this possible even without a persistent presence, though obviously with a limited window.
History-Based Attacks (Passive)
Additionally, if the attacker can see an absolutely vast amount of changes to a single file (perhaps millions), they may be able to leverage that information to gain even more insight at the math level, not just metadata.
Realistically probably not, though. No known attacks actually exist, and Dropbox-synced files generally don't change enough times for the proposed attack patterns to be relevant. And even if they did, Dropbox doesn't just let you download a set of millions of old revisions to a single file.
Write-Based Attacks
If the attacker can write files that you will attempt decrypt, then now you've got some real problems. At the very least, the attacker can selectively delete or destroy files. They may even be able to guess which files to break by using the metadata as a guide. Additionally, they may be able to break only certain parts of a file.
And remember the bit about the sparse files; an attacker can zero out huge chunks of a file by zeroing out the corresponding ciphertext.
Additionally an attacker with write access to your Dropbox could revert the file to a previous version... though that's also an explicit feature of Dropbox. Which sorta brings up the point that if you consider platform features themselves as a serious vulnerability, then you gotta ask yourself whether Dropbox is really what you're looking for to begin with.
And that's the whole point here. There's a lot of benefit to layering client-side crypto on top of a cloud sync service, sort of like a second layer of defense. But if the guarantees you're trying to produce run explicitly counter to the features of the underlying platform, then you're probably trying to hammer a square peg into a round hole. You might be able to produce a functional solution with carefully chosen tools, but your overall experience is going to be worse because the underlying service is optimized for doing precisely what you don't want.
Interactive Attacks
If the attacker can modify the ciphertext and then see what the plaintext was (or whether it successfully gets decrypted at all), then they presumably could make millions or billions of file changes to zero-in the decryption key. There isn't a known attack to actually derive the key. But if they could do it then it'd be the master key for the whole volume, which is the main reason which that fact is worth bringing up. And one of the protections against this (the MAC settings) may be easy for the attacker to disable.
Also, if the attacker has code running on the victim's machine then they may be able to leverage timing information to gain insight into the key. Again no actual known attacks, just speculation. And in these cases, the attacker is typically well-positioned enough to not actually need the key.
Conclusion
For your typical "personal files" use case and with the typical attack model, EncFS is generally fine. If offers a level of protection that would satisfy the average user's expectations, even considering Dropbox's file revision history. The main caveat there is the Metadata thing, since it's the most reliably exploitable part of the story, and people rarely put much thought into how much an attacker can learn from just metadata.
But for more serious protection, especially if this is playing into some sort of automated or shared setup, then you probably want to encrypt a disk image rather than this sort of pass-through system. And you probably don't want Dropbox either.
