Hi @Avi!
To start with the more specific part of your question:
To add to what Andrew already said I think the GIF in this @metabase tweet demonstrates it quite well:
https://twitter.com/metabase/status/935639738995879936
In general skimming all the GIF's in the @metabase twitter feed with most of the recent ones marked #TipTuesday is highly recommended!
Then onto:
Good ... I guess you are referring to the So about those joins blog post?
Under the "In the meantime" heading there's actually a link to that you can do all the native SQL queries that you must do (if you're the one among your colleagues who already understand JOINs).
I think it's also put quite well why they choose to hide JOINs so much with this further down:
...The easiest release valve for this is to just slap three joins in every query. Once you go down this road, well then, yes, Join Support is a must-have in any analytics tool you use. However, by making queries that an end user would naturally like to ask require joins, your data model is implicitly saying you don’t want end users to ask their own self-serve questions. We think this is quite limiting.
Finally a few pointers to related topics here: Is it possible to create a metric with join table? and Create questions from multiple tables (SQL Join?)