I’ve been using the recommended “accept established,” “accept related” firewall rules for years at the top of the input chain on my routers. Today, while debugging a problem caused by my errantly dropping all incoming traffic (including replies!) to the NTP port on my gateway router, it occurred to me that I did not have those two rules at the top of my forward chain. A web search shows that their use on the forward chain doesn’t seem to be popular. If I put these rules at the head of my forward chain, am I opening myself up to undesirable side effects?
It’s the first rule to be set - so that 99% of you traffic won’t wander through your firewall.
It depends on what else is in forward chain. Sometimes stateful firewall is not the goal. But a lot of what you can find on web is “look mom, I’ve configured my first router and it works!” kind of stuff. The fact that their router has zero security doesn’t bother many people, because they don’t see it, it works at first sight, so it must have correct config, right?
But if you want to have proper stateful firewall, you can’t do it without connection states. You don’t absolutely have to put “accept established & related” as first rule, but in most cases it’s what you want, because it’s most effective.
Btw, just for fun (kids, don’t this at home!), following is actual real supposedly super-secure firewall I’ve seen recently. The admin was paranoid and blocked access to all external resources by default (at least he thought so) and if someone wanted to connect somewhere else, it had to be whitelisted. Try if you can spot the basic flaw in his thinking. It’s harder than it looks, mainly because you’ll struggle to believe that it might be real. The config in all its glory (no essential parts were omitted):
/ip firewall filter
# allow connections from workstations LAN to various services on external servers:
add chain=forward out-interface=workstations_lan protocol=tcp src-address=a.x.x.x src-port=1433 comment="remote mssql"
add chain=forward out-interface=workstations_lan protocol=udp src-address=b.x.x.x src-port=1194 comment="remote openvpn"
add chain=forward out-interface=workstations_lan protocol=tcp src-address=c.x.x.x src-port=20-21,1024-65535 comment="remote ftp"
<another ~100 rules similar to the above>
# allow connections from workstations LAN to standard services:
add chain=forward out-interface=workstations_lan protocol=tcp src-port=20-23
add chain=forward out-interface=workstations_lan protocol=tcp src-port=25,110,143,465,587,993
add chain=forward out-interface=workstations_lan protocol=tcp src-port=80,443
# allow traffic from/to remote networks (IPSec tunnels):
add chain=forward dst-address=192.168.x.0/24 src-address=a.b.c.d/20 comment="workstations to remote"
add chain=forward dst-address=a.b.c.d/20 src-address=192.168.x.0/24 comment="remote to workstations"
add chain=forward dst-address=192.168.y.0/24 src-address=a.b.c.d/20 comment="servers to remote"
add chain=forward dst-address=a.b.c.d/20 src-address=192.168.y.0/24 comment="remote to servers"
<another ~50 rules for remote networks>
# drop everything else, to make the network safe:
add action=drop chain=forward out-interface=workstations_lan
# that's all, folks!
This guy needs to read again the meaning of “out-interface” in the filter… And having a look to the packet flow would be useful, too… Especially knowing that the traffic is bidirectional and where it’s placed the router in his network… 
Also: router itself is wide open to internet … no rules for chain=input …
To be fair, there was something in input, I skipped that, because I wanted to show only “creative” approach to forward filtering. Input ended with drop rule, so it wasn’t entirely bad, except that the rule also had dst-address=. So it was safe from random strangers on internet, but evil hacker who would be in ISP’s network and could route anything to router’s WAN interface, could simply use router’s 192.168.x.1 LAN address as destination and connect to any service. But at least www service was disabled and RouterOS version was from way before WinBox bug appeared, so it was safe after all. 
The whole thing looked like the guy didn’t know about connection-state=established and tried to work around it. Which is hard thing to do, when you also want to block stuff. If you don’t block anything, or block just a little and default action is accept, you can live without stateful firewall. But if you want to block everything by default, it’s a problem, because without connection states, you can’t tell reply packets from unsolicited ones.
So in short, rule to accept packets for established and related connections is definitely a good thing.
You should also understand that stateful firewalling in the forward chain is only acceptable when your router is the single device through which all traffic passes.
This is true in many home-and-small-business usage scenarios where the router is between local networks and the internet, but when you have a meshed network with several routers, (wireless) links between them, and some form of automatic routing (BGP, OSPF) then stateful firewalling in the forward chain should never be done. You can block some undesired traffic and some way to do that efficiently would be to first accept established/related and then have a list of protocols/ports/addresses that you block, but then at the end there should be an accept, not a drop. Because unrelated traffic has to be passed, not dropped. The established/related rule then only acts as a common case shortcut.