One inline -- does that work?

As a general philosophical thing which is really outside the scope of this change, APIs like $query->withStatuses($list_of_statuses) are generally better than APIs like $query->withStatus($status) because they're more flexible. Long ago we had some withStatus(...)-style APIs, and still have some vestigial versions of them in Differential and Maniphest I think, but users inevitably wanted things like "all open statuses", not just a single status. This lead to defining status constants so you'd do something like withStatus(BlahBlah::ANY_OPEN_STATUS), which was messy and not very general.

If I was writing this stuff today, I might do withVisibilities($list_of_values) instead of withVisibility($value) for this reason. As long as there are exactly two visibilities this doesn't really matter, but if we added a third or fourth state this UI might not be very good anymore (e.g., if we add a "retracted" or "scheduled to publish later" state, a single dropdown won't handle that very well, and storing a single integer as the saved storage value will require some glue to work with the new checkbox or typeahead control. It seems at least vaguely plausible that we'll add a "retracted" / "archived" sort of state in the future to let you throw away a draft that you decide not to move forward with.

For things with exactly two options that we're pretty sure will only ever have two options (e.g., "archived" on Projects), you can use PhabricatorSearchThreeStateField to build a "Don't Care / Yes / No" field, which is more flexible than a single checkbox.

I think this is basically fine as-implemented, though. If we do add more visibility states, the amount of glue we need is very small, and Phame is a prototype anyway.