Now, the “main issue” (i am making a separate post so that it can be corrected more easily in case of mistakes when/if anav or some other more expert member happens to see it)
6) the original rule (without comments, reordered, dissected) the chain is the forward one:
action=drop ← “negative” applies to packets that match the following rules:
in-interface-list=WAN ← ONLY those coming from WAN (let’s call this “inbound traffic”)
connection-nat-state=!dstnat ← NOT dst-natted
connection-state=new ← as stated by anav redundant, but actually restricting the width of the rule
Compared to the three rules by anav in the referenced post:
http://forum.mikrotik.com/t/drop-all-from-wan-not-dstnated/159152/1
http://forum.mikrotik.com/t/drop-all-from-wan-not-dstnated/159152/1
action=accept ← “positive”, applies to all packets that match the single rule below:
connection-nat-state=dstnat
action=accept ← “positive” applies to all packets that match the following rules
in-interface-list=LAN ← whatever (no matter if dstnatted or not) that comes from LAN
out-interface-list=WAN ← AND that goes to WAN (let’s call this “outbound traffic”)
action=drop ← “negative”, whatever remains at this last rule is dropped, NO EXCEPTIONS
So we can try to rewrite in plain(er) English:
Original:
Do NOT allow inbound traffic that is NOT dstnatted. (this could mean “allow dstnatted inbound traffic”)
Anav’s set (implying the final drop all else):
Allow all dstnatted traffic (inbound and outbound) and all outbound traffic (dstnatted or not).
It seems to me that the two are perfectly equivalent, but evidently in your current setup there is some traffic that matches the original “negative” rule but that goes through the “positive” set.
From https://wiki.mikrotik.com/wiki/Manual:IP/Firewall/Filter
connection-nat-state (srcnat | dstnat; Default: )
Can match connections that are srcnatted, dstnatted or both. Note that connection-state=related connections connection-nat-state is determined by direction of the first packet. and if connection tracking needs to use dst-nat to deliver this connection to same hosts as main connection it will be in connection-nat-state=dstnat even if there are no dst-nat rules at all.
So, it is more likely that a connection is marked as dstnat (which would “widen” the original rule) the issue is then (IMHO) more likely to be connected to a possible (mis-)classification of the interfaces (as LAN, WAN or something else) or of “inbound” vs. “outbound”. 
In any case, cleaning/fixing the /interface list member and disabling the /interface detect-internet wouldn’t (shouldn’t) make no harm.