Hi,
indeed, the “drop hostile” feature can produce quite an amount of log messages - maybe because there are so much hostile networks on the internet. 
I don’t have the numbers of any IPFire machine I administer at hand, but several thousands of them seem to be a plausible value. For attractive targets (such as machines hosting public services or being located in countries or networks commonly referred to as being interesting), one can safely expect more, depending on where the attacker’s systems are located.
A related comment to that: If the attackers are smart, they will most certainly avoid networks being flagged as “hostile” (i. e. being listed at Spamhaus DROP), and rather abuse compromised legitimated machines or rent VPSs at legitimate hosters straight away. Sadly, thanks to poor abuse handling at some IT giants, they have an easy time doing this.
To cut it short: Expect “drop hostile” to get rid of the mass scanning for you. Targeted attacks will most certainly slip through, if the attacker invested some brain cells on their business.
Regarding the logging: Yes, indeed, the log analysing capabilities of IPFire 2.x are not really state-of-the-art. However, I believe you could still gain insights from those logs, for example, by setting up a Cron job searching for outgoing DROP_HOSTILE events, and alerting you if there were any. These are certainly ones you want to know about.
DROP_CTINVALID is actually the attempt to make debugging easier: These packets have always been dropped, but were never logged. Personally, I suspected conntrack to drop some packets it shouldn’t, but could never proof that. Now, thanks to logging of these, things are more transparent since it is more clear what IPFire does and what it doesn’t.
To answer your last question: Yes, the “drop hostile” feature takes precedence over the location block.
Thanks, and best regards,
Peter Müller