There isn't always a simple example snippet to show. A realistic example of static conditions might involve hundreds of lines of code for a niche use-case that most people don't even need. It's kind of a complicated escape-hatch for when the usual picking algorithms aren't appropriate. My point is Unity can throw dozens of staff at such things, but it's difficult for us to justify. The other alternative for us is just to not document stuff like that and leave it as unsupported engine internals. Then at least people won't wonder what it means or how to use it, but I'm not sure that's preferable.
If I download the full Construct manual it currently comes in at around 900 pages. It's a huge body of work, and "just sprinkle some examples all the way through" is probably a major project that would take weeks.
Being a smaller company I think we have to rely on our community more than huge companies that can just throw loads of staff at something. For example there's no way we can possibly do our own Construct integration for all the third-party services out there - it's year's worth of work. So we have an addon SDK so third-party developers can potentially do it themselves without having to wait for us to get round to it. I think it's a similar situation with documentation - if you want tutorials for specific kinds of games, useful code snippets for specific features, demonstrations of useful approaches and algorithms, then we have a public tutorials system for that too, so the community can share their knowledge rather than relying on our already-stretched team to provide everything. To be clear, that's not an excuse for us to have inadequate documentation - I think we do a good job with the resources we have available - but when it comes to samples, guides, tutorials etc. there's just an endless array of things to be covered, it all takes a great deal of work to do well, and the fact is we're a small team.