People who are interested in using the REST api please watch and vote for the ability to delete attachments using REST.
You really don't have a CRUD api without the delete part.

https://jira.atlassian.com/browse/CONF-36015

Thanks Bill for pointing out CONF-23873, I put my vote on it. Hope to se some progess on it.

Hi Jonas, Don, Jeff and Ethan, this issue is resolved but there's an existing issue for what you describe at CONF-23873. There's also CONF-6415 which is indirectly related.

Yep, this is a no brainer! We have users who edit an excel file daily. Need a way to cap the total file space used by this...

^ this

I agree with Jonas, what is also needed is the ability to control the number of versions.

From a systems management point of view it would be great to be able to specify a maximum number of attachment versions.

Hi, folks. In 4.3, space admins will be able to manually remove a specific attachment version (see Confluence 4.3 Beta release notes).

For those interested in having this added to the remote API for bulk operations, we've created a new feature request at CONF-26182 where people can vote.

Recently opened a ticket with the subject: "Attachment clean-up options: is there a method for removing older versions of attachments?" My final comment on the ticket:

"Thank you for the follow-up William. But have to admit I'm skeptical about a resolution: CONF-3079 is 6 years old, still currently needed and there's been no progress despite Atlassian's acknowledgement that "Indeed it is a bit painful at the moment to remove a specific version of an attachment", and that "This is a useful feature and about 1-2 weeks of work. We will consider this for a near future release."

For wiki's that serve primarily as a 'official and/or latest version' document repository, having multiple revisions defeats the purpose. Not only do we not need the older versions but would rather they not be accessible. Meanwhile, out of the 56GB of attachments, I estimate 40Gb is unnecessary.

I highly recommend creating an attachment and page versioning control policy that allows admins to define a 'maximum # of versions' option and the ability to delete older versions from the system. I'll post this comment in CONF-3079 as well. Thank you for listening!"

Even just providing architectural enablement and API/Remote API support to enable 3rd party plugin/tools to provide a variety of cleanup capabilities. This would go a long way to help with this issue. Without architectural support, the only option is saving off all the current attachment versions, deleting the attachment, and then re-attaching some of versions again. This loses history and has other issues. Ideally, you just want to leave holes in the version numbering and not have Confluence stumble over the fact that version numbers are not contiguous.