I have heard of doing this practice for running some specific logic...
Let's say you have a generic Page View rule (that is one rule to set all your generic page view dimensions).
Now, let's say you have some logic that you only want to set some specific dimensions on say a "Search" page, you could create a rule to set the dimensions for Search Pages.
Then maybe you want to have other logic for Product Pages, you could have a rule to set that...
Then again, there is one generic rule to run after all of those to send the beacon...
While this could work, it's not the most efficient, and could result in "dimension" rules being missed... Even with the order being set, this is based on the start of the rule, it doesn't necessarily wait for the whole rule to finish before starting the next rule (particularly is there is there is any sort of slow logic happening).
Now, as long as everything is tested and working, in theory this shouldn't be a problem, but as more an more rules get added, or more complex logic comes into play it could start to manifest in issues.
In most cases, as @abhinavbalooni mentioned, most implementations send the beacon in the same rule....
I prefer to build my "page specific" logic into the Data Elements or into the Custom Code block of the rule.. But non-coders would find that approach potentially harder....