We'd hope to avoid a lot of the operations you estimate. And we do, by having suitable indexes available to the optimizer.
SQL (Structured Query Language) is based on the idea that we specify the results to be returned, and not specifying how those results should be returned.
A relational database management system has a component usually called "the optimizer" that evaluates SQL text, and determines which operations are to be performed to return the specified result in the most efficient manner possible.
The optimizer can consider a lot of possible options to access rows and perform joins (before MySQL version 5.6, the only join method MySQL used was nested loops) and how to satisfy GROUP BY and ORDER BY clauses, etc. With SQLite, the default order is to use the left most table as the driver of the nested loop, but SQLite will use an order other than the default if suitable indexes are available.
In terms of join "order", the order that tables are listed in the FROM clause doesn't (or shouldn't) really influence the access plan selected by MySQL or SQLite (absent any "hints" in the statement and as long as indexes are available and predicates can make use of the indexes.)
We're usually better served if we don't include hints. Those are available to us for those rare cases where other tuning efforts are insufficient and result in a sub-optimal plan. (Tuning efforts such as making sure statistics are up-to-date, making suitable indexes are available, re-writing non-sargable predicates, removing unnecessary derived tables, etc.)
While the join order can be an important component of the optimizer plan, it is only one small piece of the entire SQL tuning puzzle.
A join of a three tables ( "A, B , C of sizes 10, 10^4 and 10^6") on primary or unique keys, or even on non-unique keys won't require "10^ 7 + 10^ 5" operations if we have suitable indexes available. In that case, we are much less concerned with the join order, than we are with avoiding full table scans. The optimizer generally does a good job of figuring out an appropriate join order, unless we have written the query in a way that disallows the optimizer from considering more efficient access paths.