Despite its effectiveness, Flare is not without its issues. None of these should stop you from using Flare, because there is no other app that will do it all for you, but:
The error handling has always been horrible. When you eventually encounter an issue (usually the parser choking on some unexpected value) you will get a generic Dot Net error that will tell you nothing about the source of the error. Just set aside four hours of your day to figure it out.
You can't disable inline formatting in the interface, despite Flare's own trainers (rightfully) telling you to never use it.
The source control comparison tool is impossible to use or understand and the icons in it are about two pixels wide.
CSS styling will not always behave the same between print and online outputs. You have to have two style sheets and in some instances have multiple versions of otherwise identical content. There are still single sourcing ways to do this but they will make you grit your teeth.
The XML WYSIWYG authoring interface is always a a few years behind with CSS. Fancy CSS will work in your outputs but might turn your WYSIWYG into an unusable mess in some topics (you will have to edit some or all of the content in the code view in those files).
There is no way to maintain "two column" styles inside of list items (e.g. procedural steps) that agrees with web code conventions, you must use tables. Floats will only work in online outputs. Float results in PDF targets are dodgy.
You cannot reference step numbers without changing all list items to specially formatted numbered paragraphs that fill your HTML code with invisible tables on output. If you want to use Ordered Lists like you should, you just have to accept you will never have automatic step number cross references. You can, however, do many other wonderful things with cross references.
The WYSIWYG lets your writers put text inside dynamic elements like cross references in such a way that you will find whole paragraphs missing because it was accidentally written into a cross reference that gets dynamically regenerated at build time.
There is no way to prevent SMEs from printing their own revisions of documents and running off to the printer, so don't expect Flare to help you control your revision history.
There is no way to fall back to an old revision of a document unless you make archives of your entire project after each document revision. I have projects with gigs of assets so this is unsustainable.
Flare cannot handle encoded PNGs in your code and may break them at build time.
Much of what I dislike is actually with the companion applications. While this review is supposed to be about Flare, you might be looking at the other apps that go along with it for your needs:
The Salesforce Knowledge publishing module is a house of cards and does not support translated content. It is extremely easy to break a single source file and therefore destroy all of the links to your source content and the published knowledge articles. This cannot be fixed and you must either give up on publishing future updates to those KB articles or delete all the articles in SFDC and start over.
Capture is free with Flare! But the interface hates freedom. Unless you need to apply conditionalization inside your images or will go all the way with callouts separate from image files (ideally, you should), just use something else for screen captures/image edits.
Contributor has just as high a learning curve as Flare but only 20% of the features. In 8 years of trying I have never once successfully deployed Contributor to an SME. We just give up and buy them Flare or let them markup a PDF.
Madcap Central is extremely expensive and still does not allow you to build a workflow among your team. You can make assignments, but they are not linked to the files in your project so you may as well have just put the assignments in something else that provides analytics and reports. You barely get any webserver space for what you pay.