I agree with you. What makes me lean towards my solution is that I can pass the plate to the WordPress documentation if anyone else want to know what the code i

I agree with you. What makes me lean towards my solution is that I can pass the plate to the WordPress documentation if anyone else want to know what the code is doing and we can follow the trail of callbacks and hooks while that request check can be (and in this case, is) sprinkled all over the codebase. What I noticed is that people following the first method ends up hacking core functionalities of WP because "it just works" but in the end that makes the code unstable and harder to maintain because it relies on undocumented stuff and a coding style that is very personal. It can also messes big time with stable things expected from the CMS (mangled taxonomies, hijacked hooks in the core instead of the WP pile that make it hard to debug or to play nice with other plugins/themes).