ok so there are a few things here.
in a traditional design with FHRP you would have an active/standby setup. in this case if your transport is connected directly to the FHRP routers this means your transport is only being utilized on one device. you can do manual load balance by setting priorities for different HSRP groups. alternatively you can use an aggregator that would terminate multiple transports and connect the fhrp routers this leads to a single point of failure but allows the use of both transports. the third method would be to have a connection to both transports connected to each FHP router. this may incur extra costs for a third IP address .
with sdwan you can use the same methods as above but aggregator is not recommended due to the single point of failure and lack of ability to split traffic dynamically such as AAR. tloc-extension allows the addition of the peers transport to avoid the extra cost of additional ip and allows the use of dynamic load balance across multiple transports.
so to answer your questions
1) Why traditional router doesn't need TLOC extension?
- this requires a different design using routing to allow utilization of multiple transports. Iwan used some trickery with GRE tunnels between dual hub or or dual branch routers to achieve a similar effect for example. allowing the use of multiple transports
2) Why second box need to utilise uplink connected to the first box? For what purpose?
- to allow the use and load balance traffic across multiple transports instead of having an idle or "backup" link that you are paying for but not using. Also as mentioned it avoids the issues with aggregator and with paying for extra ip addresses from your ISP.
3) What will happen to SD Wan if we dont use TLOC extension?
- not using tloc-extension would prevent the benefits mentioned above including idle link, aggregator issues or paying for extra ip addresses. it will not allow the full use of the benefits of sdwan which include load balance and AAR to start. You may also have a private transport (IE MPLS) which may not be able to directly reach the controllers or may have restrictions for internet access which would change your design. For example DIA may not be viable on a private circuit. A single transport connected to the vedge/cedge would not really be a good use of sdwan and misses the concept of load balance or application aware routing taking the "best" path
hopefully this makes sense.
