Think of it just like querying SQL directly. It's the number of rows that SQL Server has to 'read' to determine if that row is to be returned. With an index, SQL Server knows which rows to get without having to read them. Without an index, SQL Server has to read every row in order to determine if it needs to retrieve it.
Same in SharePoint. If SQL Server can deliver < ($LVT) rows to SharePoint before SP has to filter it any further then that's ok. If the number of rows to be delivered to SharePoint is > ($LVT) then the query is halted.
Effectively, SharePoint refuses to even look at any result set (including all the joins, etc.) coming from SQL Server (because essentially, that's the nitty gritty of it) that is > ($LVT).
Regarding your view statement. Your view determines the queries that will be sent to SQL Server so if your default view causes the LVT to be exceeded, the list will be inaccessible unless users visit and alternate view explicitly.