people.disable_spam.users

You don't want capability to actually spam users.

What is this about?

Its even logically seems wrong. With proper controller implementation you should be able to add new controller and implement logic there without modifying other controllers.

$has_spam is ambiguous: is it about the profile itself containing spam?
What you mean here is $has_disable_spam_capability.

$can_disable_spam.

Also, there is no way to handle hierarchical capabilities in the interface, typical capability checks in the code do not support this, and the code in the controller is written in a way that it only requires spam disable capability. So this line should really be $can_disable_spam = ($has_disable_spam_capability && !$is_self).

Disable as Spam

Why do you need $via here? You don't route permissions differently for the admin panel and X actions.

Indentation?

Consistency, and canonical. While TRUE would work, the canonical way of spelling is true. This is also what you've used in other areas of this patch.

PhabricatorUserDisableSpamTransaction

user.disable_spam.

Wording is important. Making it clear what performed action is also important.

While the statement in the comment is valid, we are in the "disable user as a spammer" action. This actions is, based on reading code above, supposed to have own dedicated capability. which is not validated here.