I always thought I need to open incoming ports like UDP500, UDP4500 and ESP protocol to allow IPsec tunnels to work.

I'm configuring a new router now, latest RouterOS, default configuration, just configured IPsec peers and policies... And see what tunnels are working without any additional filter rules as described above.

The question is: is it really needed to have a special allow filter rules to allow incoming IPsec traffic?

Actually, yes. Cause you always have to receive input traffic. If you forward him through router and other side have no good firewall, it will work, because input connection back by yourself ins related and will be accepted. But, if your router have no clue of some input connections from initiator - these will be droppped.

ISAKMP Ike is Using udp500 to handle key setup (This is only needed if you use ike)
NAT-T Traversal UDP Encapsulation is using UDP4500 (This is only needed if you need to support NAT)

IPSEC can't function over NAT. Here UDP Encapsulated IPSEC packets may be used. Depending on what types of IPSEC you need it MAY or MAY NOT be required to accept that UDP traffic.

UDP is IP Procotol (17)
ESP is another IP Protocol (50)

IKE and ESP Is NOT Fond of NAT. For them NAT is an abomination. Ike has, with extensions later on, got support for nat (nat-traversal) but it is HIGHLY not compatible between implementations because badly written rfc's with many cases of undefined behaviours.

Hope that somewhat explains what, when and Why.
Ps. Don't open holes in your firewall that you don't need for you implementation. Whit that said. If you Look at the default config script Mikrotik has already opened this for you... But why support nat-t if you don't need it? Ds.

NAT-T is needed, if initiator/responer have no globally routable IP.
It's you to deside what you need to open.

Actually it will work just fine without those firewall rules when you have an "accept established/related" rule and you have a symmetric IPsec tunnel (not one active and one passive side but both active), with regular traffic.
Why? Because both sides will attempt to contact the other side at the same time, will put an initial short-lived connection in the firewall that will match the request from the other side as being a reply to the own reques, this will kickstart the connection and establish long-lived connections that will pass the traffic.
This also works for ESP (as long as there is "somewhat regular" traffic)

Of course there could be problems when NAT is involved (when it includes port translation) and in any case I would consider it better practice to explicitly allow what is required.
But in case you wonder why it works without any extra firewall rules or why the counters on your rules always remain at zero, that is why.