@Clive_A 
This is not a solution.

https://community.tp-link.com/en/business/forum/topic/613834?replyId=1223124 refer to another router ER605 that costs 30% of what I've paid.

https://community.tp-link.com/en/business/forum/topic/712650 refer to yet another router ER7206 (TL-ER7206) that do not suffer from the same bug, according to TP-Link stuff.

Confirmed by the support team, there is no Hardware Offload on the ER7206, so the ER7206 doesn't have the issue.

Please refrain from posting random links.

There is yet another discussion on https://community.tp-link.com/en/business/forum/topic/261604 . It says:

It's because that the Hardware Offload is enabled by default on the ER605, the packets are forwarded directly through the hardware rather than through the CPU, which results in an inaccurate statistic.

Why I don't accept this as an answer? 

1. This is a called 'the root cause of the bug' and shouldn't go any further than Jira tickets comments, unless customer requests it. There are no circumstances when 'the root cause of the bug' is accepted as a bugfix.
2. I really don't care about the details of internal TP-Link software/hardware implementation. Building routers is not my business. If I buy a router for 150 USD, I expect it not to have silly and childish bugs that made it through QA and into the release, accompanied by the naive “hardware acceleration” excuse quoted above. Nor do I accept using 'hardware acceleration' phrase as an excuse for not providing the fix.
3. Hardware acceleration has been in routers for decades, but this is the first time I've encountered the notion that traffic should legally bypass interface statistics, IP statistics, DPI, IPS because of that.
4. When I was considering between ER706W and ER7206 (same price), there was no disclaimer provided by TP-LINK saying it failed to implement some very basic functionality properly.

I will try enabling Bandwith Control as suggested in https://community.tp-link.com/en/business/forum/topic/261604 and see if it works.

  @Serge9000 

I will try enabling Bandwidth Control as suggested in https://community.tp-link.com/en/business/forum/topic/261604 and see if it works.

It worked indeed.

However, this exposed another problem - a WAN bandwidth bottleneck due to CPU capping (my WAN interface is a dynamic IP). Sometimes the cap was as low as approx. 200 Mb/s (*depends on traffic type). For a semi-pro 1Gb/s router this was a bit disappointing. 

It turns out that Bandwidth Control=on must be accompanied by DPI=off, or be prepared to suffer a CPU bottleneck otherwise.

P.S. TP-Link advertises this router as being able to 'check network usage and traffic distribution'? (* ER706W(EU&US)1.0_Datasheet.pdf)

Update.

Another week, another firmware bug :( 

Now the router is insanely overestimating statistics instead of underestimating it. My PS5, smartphone, PC and even a humble IOT device are reported as having enormous TX bytes. 

Example: smartphone [IP address reserved by MAC].
Router uptime is 1 week. Router reports smartphone's  Total TX Bytes=87G and Total RX Bytes=48G.

Smartphone reports the whole 'WiFi data usage' is 23GBytes only (for 3 weeks).

I wonder what will excuse be this time?