Not every app needs to send email or store data to the cloud. While most apps need to manage background jobs, the way in which this happens is highly dependent on the environment the app runs in.

Further, when sending email, it's often better to use the email provider's API. When emails are managed inside the app, this can create difficult in iterating over the emails or taking advantage of the provider's APIs.

Cloud storage and background jobs are often extremely specific to the infrastructure and environment. Even with an abstraction, developers still need to understand the specifics of how e.g. S3 or Sidekiq actually work. Because of this, the app is simpler and easier to understand when it uses these APIs directly.

By providing an API to wrap email, cloud storage, or background jobs, the app must provide either a lowest common denominator API or an API that is highly complex and conditional so it can handle the specifics of the many providers that are out there. Skills using such an API against one provider are barely transferable to another. The API in question ends up getting in the way.

Including some of these APIs, or more rudimentary versions didn't seem worth it, at least not without some really clear cowpaths.

This will make Brut overall simpler, since it will do less. It will also mean that a Brut app that uses email, cloud storage, or background jobs will itself be simpler since it will depend directly on APIs that the app's developer will already need to understand.

This does mean that app developers will need to learn an email API, cloud storage API and/or background job API, but they would need to do these things no matter what.

Email, background jobs, and cloud storage are not commoditized like HTTP or view rendering is. Thus, an API to wrap them would require developers to learn two things with no added benefit.