I'm ambivalent about this action in most cases, but in some specific cases there can be a clear reason to have an exposed database: namely when the database is a guest-accessible, read-only repository of public data, i.e. the self-hosted equivalent of publishing a Google BigQuery dataset.
As someone who runs such a "public-access data library" myself, I would be slightly annoyed if someone came along and burned it down, just because it has an unpatched vulnerability.
...but if it got deleted because I left default admin creds on it, though, that'd be my own fault.
Read-only in practice, not inherently read-only in the way that e.g. CD-ROM is. Such systems still need to have their otherwise-static dataset updated "online" by an ETL pipeline agent-user. Which often means, in the DBMSes with less fine-grained security models, that such users need to have full DML (and even DDL) capabilities, rather than only insert capability.
As someone who runs such a "public-access data library" myself, I would be slightly annoyed if someone came along and burned it down, just because it has an unpatched vulnerability.
...but if it got deleted because I left default admin creds on it, though, that'd be my own fault.