The largest of development organizations, like Google (as mentioned) and Facebook practice it at scale. Over 30 years different advances to source-control technologies and related tools/techniques have made Trunk-Based Development more (and occasionally less) prevalent, but it has been a branching model that many have stuck with through the years.
A key facilitating rule is that Trunk-Based Development teams exclusively either release directly from the trunk - see release from trunk, or they make a branch from the trunk specifically for the actual release. See Branch for release. Teams with a higher release cadence do the former, and those with a lower release cadence do the latter.
A portal on this practice Styles and Trade-offs # There are broadly three styles of trunk-based development as a daily developer activity. Depending on the number of developers in the team, the release cadence, and the desired rate of commits (assuming story-sizes that support that), you have trade-offs for each of the three: Committing Straight to the Trunk # Suitable for active committer ...
Lean Experiments can happen in any development team on any project but work best on foundations that are solid. Specifically, the solid foundations of Trunk-Based Development, CI, and CD.
Story size # Trunk-Based Development needs you to have small stories/tasks. Optimal is you starting work on a change, should only be a matter of hours before completing and pushing it forward for code review. Longer than a couple of days, and there is going to be pressure to group a bunch of developers on a non-trunk branch and merge back later.
To facilitate that, it is common for Trunk-Based Development Teams to make a release branch on a just in time basis - say a few days before the release. That becomes a stable place, given the developers are still streaming their commits into the trunk at full speed.