This sounds like an uncomfortable kind of meeting. I often find myself saying "we can easily look that up".
Knowing where and how to effectively look things up is a critical aspect of knowledge.
It depends on what you need to look up: I don't need to know that the Eiffel Tower is hold together by 2.5 million nuts, bolts and rivets (I looked this one up), but as a western european, I should know that the Eiffel Tower is made from some kind of iron.
OTH though, if I'm the company in charge of maintaining the Tower, I should probably know more about it. So it really depends.
Facts become information, information becomes knowledge. Learning is about processing what's in front of you. Becoming aware of facts presented to you in a book or a powerpoint presentation, then reflecting on those facts, turning those over, engaging with them, asking new questions, trying to apply them in different contexts and so on.
As you do that, the entire experience of gaining knowledge also leads to self reflection. That is, learning to know yourself. And others around you. When does it matter to apply what you know? When not? What is relevant to me and to those around me at which point? This is about learning to formulate effective critical argumentation based on what you know. And that involves challenging viewpoints including your own. Context matters.
The latter is a skill. It's something you need to practice if you hope to be any good at it.
Expanding on your example:
I think it's important for engineers to have a proper understanding of the details about nuts and bolts when they are actually building the Eiffel Tower. But in a meeting with stakeholders - the mayor, city officials, banks, sponsors,... - it's also about knowing that they probably don't care about those material aspects. Unless the context changes and those become super important. Like when it becomes appartent that the iron wears out because of changing weather conditions. And even at that point, those stakeholders likely aren't interested in the exact chemical formulae that explain the process unless it's necessary to cover risks and liabilities. They simply want a good, terse explanation from an expert and an assurance whether it can be solved.
Hence why knowing things isn't enough. It's about knowing how and when to apply them effectively.
However, the reason why it is so useful is because it gives you more room to use for the stuff that really matters.
Knowing stuff has much lower latency than looking stuff up and having the ability to quickly correlate multiple relevant facts and draw connections allows for much higher capabilities and productivity.
They key is figuring out which stuff you need to know to be able to quickly build and evaluate mental models and which stuff is best looked up.
In practice, you see that with non technical managers all the time. You see it when people just throw around smart sounding soundbite about history if you happen to know period well.
Many charizmatic confident people rely on others not checking what they talk about.
Maybe I need to clarify, with "you can't lookup informations" I meant a meeting (or an exam) it's not the place and moment where you verify if a piece of information is valid or to learn something completely new, it's the place and moment where you put what you already know about something at work.
Knowledge is mainly about recognising patterns, if you know something can be solved with a certain formula you can look it up, it's not easy to keep everything in mind, but you have to already know what to lookup (at least the general domain of the problem)
In my experience if I attend a meeting about (for example) implementing the new company SSO component, I go there assuming we all know what an SSO component is, what it does and that each participant understands the problem for their angle (business, technical, legal etc. etc.)