The reason "plrcanbeseen" is seperated into two actions is because it CAN accept a parameter that is not correlated to whether or not the player can directly be seen. It specifies bounding parameters for the check, specifically it alters the viewing cone to be used for checking whether the player is visible or not. You can see this in effect in some of the legacy AI scripts.
I personally like that they use the 1/0 structure instead of the "can/cannot" structure. It saves a LOT of code to be written in the engine. Instead of writing two commands, you can just write one command that accepts a parameter of 1 or 0.
The "plrcanbeseen" and "plrcannotbeseen" commands are not like the other ones you've listed to accompany them in their "category". "plringunsight" does not have an opposing condition "plrnotingunsight". "hudhavename" doesn't either, nor do we have a "cannottake" condition.
A more suitable condition to be accompanied with "plrcanbeseen" would have to be "plrdistwithin", which is opposed by "plrdistfurther".
In all honesty, I think it should stay the way it is. People are already used to it, and it makes sense when you think about it.
The one and only,
