Programmer Humor

User is saying something in a DB that doesn't change should not reside in a Database because it's functionally static.

But user doesn't realise why that static data is kept in DB.

Is this position against lookup or read-only db tables?

Largely, yes.

The kind of cases where I've seen people stick things in the database that I thought would better be elsewhere:

• If it's small and doesn't need to change between releases, you can save all the moving-part kind of overhead of pulling that data from the database just by throwing that data in the source code. Often times people do this just so they can have a "foreign key" to something in the data in question. But a nice, semantic "enum" sort of field in the database can refer to something static that's already in memory no problem.
• If it needs to change at an administrator's or developer's (or manager's) whim, it's probably configuration, not dynamic data. In the Java ecosystem, Spring Cloud Config makes it easy to change configuration without releasing the code. (I mean, in a perfect world, releasing should be as easy and straightforward as changing configuration, but not everyone lives in a company where all the managers have read The Phoenix Project and caught the DevOps bug.) Putting configuration in the database tends to create a big audit trail gap, unless you spend a bunch of effort building a custom audit trail kind of system.
• If it's big and not (very?) relational, it may be better suited for files in a directory. This can be true even if it does change based on user input. (Users uploading images, for instance.)

Mind you, certain kinds of behind-the-scenes users can still qualify as "users" for purposes of considering whether "it needs to change based on user input". For instance, if your marketing department (without software engineering expertise) needs to be able to mess around (without software engineering assistance) with marketing materials displayed on customer-facing websites, you probably need a content-management system of some sort, and I don't think the database is necessarily a bad place to store a lot of that information. (Things like images probably shouldn't go in the database, but metadata about those images are probably quite reasonable data for the database.)

Also, I'm rethinking the term "user input". I could certainly see it being reasonable for automated systems to put data in the database. Like, if you have a scraper doing stuff to be displayed to end users, that doesn't belong in the source code or configuration, and if it's very relatioal, it could well belong in the database. Maybe it'd be better to say "if it doesn't change based on client input, it doesn't belong in the database."