Because they are not in the business of filtering spam they are in the business of receiving and delivering messages. The spam filtering outbound is to protect their own core service. Running spam protection for your own service is a lot different to offering spam protection for customers.
If you're going to hold people responsible for meeting a metric, you need to ensure they have a way of measuring the thing in question. To do otherwise is unreasonable by definition. If Twilio's definition of "sending spam" matched the OP's, where it's about sending messages the user did not agree to receive, then that would be reasonable. But instead it's something more intangible.
And like you say, they do need to prevent their system being used for sending spam. But if they're not going to provide a way for honest parties to avoid sending spam, they need to be reasonable about how they react to spam reports.
You weren't sending spam just relaying is saying the same thing. Otherwise you could spam yourself and use that to send messages to a group of phones who could do the same thing. See the problem? I'm sure if this was a feature it was already exploited and patched.
Do you not see how spam protection for customers IS spam protection for your own service?
They already detect outgoing spam. Good customer service in this case would be to detect that a customer is attempting to send spam and blocking it and potentially notifying them about it.
