There are two extremities - one is to keep using one of the WANs for all the connections as long as it works, and only use the second one if the first one fails, and the other one is to distribute the traffic among both of them per individual connection (so two consecutive reloads of the same web page from the same browser on the same PC may end up using distinct WANs). And then there’s the scale between those, where you can e.g. distribute the connections among the WANs solely based on the source address, i.e. the same PC in your LAN always uses the same WAN unless that WAN is broken; for some connections, you can override these rules and either prefer a particular WAN (i.e. still move the connection to the other one), or even never try the other WAN if the desired one is broken (the latter relates to cases like VPN tunnels you use for redundant remote access to your router, some ISP-provided mail or DNS services that only respond requests coming from addresses provided by the ISP, some IP telephony services, …).
The key to all this is policy routing - you create a dedicated routing table for each category of traffic (prefer WAN 1, prefer WAN 2, exclusively use WAN 1, exclusively use WAN 2), and you create rules assigning the routing table names depending on some other attributes of the traffic than the destination address alone.
In order to use policy routing for redundancy purposes, you have to activate a mechanism checking transparency of the WANs all the way to the internet and deactivate the routes if there is a problem.
Further reading is http://forum.mikrotik.com/t/advanced-routing-failover-without-scripting/136599/1 and http://forum.mikrotik.com/t/static-default-route-im-missing-something/119183/9
Specifically for PPP and LTE interfaces, before trying anything deeper, check what address is shown as network in /ip address print for rows related to those interfaces, and whether this address changes when you disconnect and reconnect the interface. The thing is that whilst with point-to-point interfaces it is enough to use the interface name as the gateway item of a route, for recursive routing, this was impossible in RouterOS 6, I’m not sure whether it has changed in RouterOS 7.