Who rated this post

Indeed, ordered layers are most useful for restricting / dropping certain traffic. Especially if such a restrictive policy is relevant to multiple policy packages.
It's useful to separate the logic to its own layer, and you have the safety that if you do accept some traffic, it will still be inspected by the rule definitions in the next ordered layers, so it will not violate the organization's policy.

Even some of Check Point's own products use this mechanism. Playblocks adds an ordered layer to dynamically quarantine infected hosts or block suspicious external attackers. IoT uses an ordered layer to define which domains each IoT device is allowed to access (usually by vendor).

Some customers use ordered layers with an "Accept" cleanup rule. For example if defining an Internet Access policy, you want to allow or block certain categories or sites, but unless stated explicitly, you traffic to the Internet will be allowed. Such a layer will not conflict with other ordered layers as it's not blocking by default.

Cool tip:
It's not commonly known, but when a connection matches on multiple rules (each in a different ordered layer), the logging logic will aggregate the Track option in all the matched rules. This means that you can add an ordered layer just for increasing the logging level on certain traffic (even if the primary layer set Track=None on the matching rule), which can be useful for troubleshooting.

So for example, you can have an ordered layer with just three Accept rules, the first with Track=Detailed Log, second with Track=Log and third with Track=None.

You can use static objects (networks / groups) to define which source / destination will have more logging, but for an even cooler effect, you can use the dynamic object of your choice (such as Network Feeds, Generic DataCenter or simple gateway-resolved dynamic objects).

If you are troubleshooting and need detailed logs, just add the relevant network to the dynamic object contents, and without having to push policy, the gateway will immediately start sending detailed logs on those connections.
When searching for these logs in the log view, just copy the rule UID (right-click on the rule) then paste it in the log view search, and you'll see all logs that matched that rule (which will include various matches in the primary ordered layer).
You can even paste the UID in a SmartView report to filter a full report just for the traffic that you are now troubleshooting.