Answer
Rather than a fixed rule about which specific layer to add a join at, the more useful general practice is figuring out which columns are actually indexed on the underlying tables involved, and structuring whichever join/filter you add around those columns, regardless of which layer it lives in. To find this out: open the relevant screen in the client and check the System Info at the bottom to get its underlying view name; if that view name has a _TAB suffix it directly names the physical table, otherwise trace it back to the table storing the actual data; then, in a read-only PL/SQL tool, inspect that table's key and index definitions to see exactly which columns have supporting indexes. Building your join conditions and WHERE clauses around those genuinely indexed columns, wherever in the IAL chain the join happens to live, is what actually drives performance, more so than which specific IAL layer the join is written into.