I may well be too much a believer in google power, but the day 8.8.4.4 (or 8.8.8.8) [1] will not respond to pings, likely it is because the sky has fallen over our head.
But it is of course perfectly fine to also have a route to the Cisco DNS as ECMP.
I don't see much differences between the documentation example and what we do/did here, the method I extracted from CGGXANNX extensive knowledge is simply ( just because I made the spreadsheet 
) clearer, the base "new" concept of having a "normal" route working and then split it into two (the "narrow" and "wide" one) is more intuitive and - unlike the Mikrotik documentation - I try to explain what the routes and settings do.
Mikrotik has (under the hood) some special provisions to "adapt" the target-scope and scope of the routes, so you can get away with some defaults but setting them explicitly to the "right" values makes the whole stuff cleaner and more understandable, besides - hopefully - more resilient to possible changes in new RouterOS versions.
Also there is a line somewhere drawn between "SoHo" devices that come from factory with a (good) default configuration and "pro" devices that come with no configuration.
On devices that have the default configuration a very important part (to have the firewall filter rules work correctly) is the categorization of the "WAN" ports as WAN in interface list member, and there is already a nat rule like:
/ip firewall nat
add action=masquerade chain=srcnat comment="defconf: masquerade" ipsec-policy=out,none out-interface-list=WAN
that already covers natting just fine, so making two for two interfaces like in the example:
/ip/firewall/nat
add chain=srcnat action=masquerade out-interface=ether1
add chain=srcnat action=masquerade out-interface=ether2
makes no sense.
But if you start from a blank configuration and/or use a different from default firewall, they start making some (little) sense.
Making all people ping unneededly the second (and last) gateway does not make sense in any case.
The good guys that write the official documentation very often give as granted pieces of information/knowledge (either general networking or Mikrotik specific) that the average reader of the documentation actually likely misses, creating a sort of catch 22, people that need to read the docs cannot understand them and people that can understand the docs do not need to read them.
All this said, in the special (but very common) case of a primary connection and only a second failover one, I still find simpler to use Netwatch as in here:
Simpler Failover for two Gateways I found working - #19 by jaclaz
[1] personally I am not too keen of using 8.8.8.8 as check-gateway because it is not unheard of of devices that have DNS hard or soft coded to use it as DNS (and might cause issues) and I prefer 8.8.4.4.