I pretty much copied inboxCapabilities from your FEP actually, so that’s why it looks similar 
The main objection is that the concept of “server support” is not well-defined in ActivityPub; as nightpool points out above, clients are expected to do most of the work here in interpreting activities, with the server only being responsible for the standardized side-effects documented in the ActivityPub spec (such as managing followers/likes/shares and their associated collections).
The reframing suggested is to signal that a) this actor is generally not using C2S, and b) whatever external mechanism is processing this actor’s inbox expects activities to take one of a set of predefined shapes.
So instead of trying to make this “server-wide”, it should be scoped only to a single actor and their inbox.
Again, one can imagine a situation where “special purpose” actors (typically pre-programmed bots) exist on the same server as more traditional fully-fledged C2S actors. This is possible because there is no mandated mapping between actors and users. You might have an actor that exists only to send and receive reports, for example; it might be presented something like this:
id: <reportingActor>
type: Service
inboxCapabilities:
- Flag Object
The other critique I have for this FEP is that it’s probably not a good idea to separate activities / objects / properties. You would most likely want to have information about the shape of the activity rather than implying that any combination of activities and objects is supported. Taking the example from the FEP, what would the support be for Follow Image? Since Follow is present in the activities set and Image is present in the objects set, one could reasonably assume that Follow Image is supported when it might not be. I’m not entirely familiar with best practices on expressing “shapes” of activities, but off the top of my head I would think to look into SHACL or something similar. So you might end up with something like this after translation into SHACL:
// ...
"inboxCapabilities": [
{
"@context": {
"as": "https://www.w3.org/ns/activitystreams#",
"shacl": "http://www.w3.org/ns/shacl#"
},
"@type": "shacl:NodeShape",
"shacl:description": "Flag activities have at least 1 object that is an AS2 Object.",
"shacl:targetClass": {"@id": "as:Flag"},
"shacl:property": {
"shalc:path": {"@id": "as:object"},
"shacl:minCount": 1,
"shacl:class": {"@id": "as:Object"}
}
},
// more shapes for whatever is supported
],
// ...
For practical purposes it might make sense to have inboxCapabilities point not to a regular JSON array, but instead point to a SHACL shapes graph (that can be loaded from its own IRI):
{
"@context": [
"https://www.w3.org/ns/activitystreams",
{
"inboxCapabilities": {
"@id": "https://w3id.org/fep/eb22/inboxCapabilities",
"@type": "@id",
"@container": "@graph"
}
}
]
"inbox": "https://example.com/inbox"
"inboxCapabilities": "https://example.com/what-this-actor-supports-receiving-as-a-shacl-shapes-graph"
}
{
"@context": {
"as": "https://www.w3.org/ns/activitystreams#",
"sh": "http://www.w3.org/ns/shacl#"
},
"@id": "https://example.com/what-this-actor-supports-receiving-as-a-shacl-shapes-graph",
"@graph": [
// include your shape graph objects here
]
}
The rest is left as an exercise to the reader. 
https://shacl-playground.zazuko.com/ might be helpful here, as would SHACL