We don't really call pandas a database either. It looks like a data processing tool/library. "real" databases have integrated persistence models, as well as discussions and design tradeoffs regarding ACID transactions and scalability. There are query planners and indexes, constraints (type, value, foreign key) and other logic that can help enforce business rules around the data. There are triggers and embedded functions too.
Still, it is pretty cool technology and I think something that will be integrated with a "real" database near you sometime soon.
BT wasn't actually billed as "database" internally, until they had to sell it in Google Cloud where the definition of what constitutes a database is much looser. Inside Google it's known as a multidimensional hash table.
I would definitely agree that's a more precise definition. Constraining "database" to only ever refer to RDBMS is what I really have a problem with.
But there really isn't a brightline between what's a table, and what's a filesystem, and what's a database. You can put a blob in a database or BigTable, and MongoDB is really close to being a flat file conceptually. You can have a filesystem or database that is content-accessible. You can have a filesystem that is atomic and supports rollbacks and can store relational data like symlinks. A virtual filesystem like LVM can support schema-like volumes on top of it.
At the end of the day it's all just technology that lets me abstract my writes so I can deal with a more simplistic model backed by certain guarantees about behavior. I want to write a program that does XYZ, not write a filesystem/database driver. From there it's all just various tradeoffs.
Still, it is pretty cool technology and I think something that will be integrated with a "real" database near you sometime soon.