OK. This is a fun one.
Execution plans are logically executed from left to right, and roughly, top to bottom. You can validate I'm right about this by looking at the NodeID for each operator. You'll see that the first node (not the SELECT/INSERT/UPDATE/DELETE node, but the first operating node) will have a NodeID of zero (0). Each subsequent node, going to the right, will have a greater value (they won't always perfectly count 1,2,3,4, etc., there may be gaps, but they'll always be higher).
Now, the reason people say to read plans from right to left is because of the data flow. While the plans logically instantiate through the NodeIDs, the data flows from the right most, top most, operator. Following the data is a valid way to understand what the plan is doing. Also, you're going to find that the output of a lot of operators changes what you're looking at in the earlier operators. You can get a query that is returning nothing but Expr1012, Expr1042 in the operators, but you think it's TableID, TableValue as the columns. Following outputs in the direction of data flow lets you understand where things like Expr1012 come from.
So, you can look at plans both ways. The key to really understanding them is knowing that, row mode or batch mode, each operator instantiates in the NodeID order. Each operator then asks the appropriate next operator for, in row mode, one row, in batch mode, (roughly) 1,000 rows. Each of these requests continues down the chain of NodeIDs until a data movement node is reached (scan, seek, spool), and then values are passed back through the chain, 1 row or (roughly) 1,000 rows.
In short, both ways is right. Hope that helps. For LOTS more detail on reading execution plans, get my book. It's free to download. Paper copies can be purchased from Amazon.