No.

Documentation and examples coexist to their mutual benefit. Technically speaking, they participate in a positive-sum game -- having some of both is better than having a lot of either.

Documentation tries to provide a global view of the system. If you have a question about the subject -- any question at all -- you should be able to find an answer somewhere in the documentation. Good documentation lists all the system's components, all the connections that exist between components, and all the issues involved in getting components to work with each other.

Examples instantiate the documentation. If the documentation is a directed graph, an example is a single path through that graph.

Both alternatives have their strengths and weaknesses.

Documentation makes sense from the accounting perspective, because we may as well collect everything we can say about a system in a single place. OTOH, that completeness makes it harder to find the answer to any given question. Finding the answer to a specific question tends to require O(n) time, where n is the number of components in the system. You can reduce that to O(log(n)) time if you arrange the documentation in a tree, but only if the reader can accurately predict an answer's location from the higher-level descriptions.

Documentation sucks for complex questions, because complex questions involve combinations of components. Combinations expand factorially, so finding all the necessary answers to a multi-part question tends to require O(n!) time.

Examples live at the other end of the scale. They suck for completeness, but they're great for giving people answers to multi-part questions. In the vocabulary of dynamic programming, an example is a memoized search through the factorially-large space of possible answers.

So for simple questions -- defined as those which involve a single answer -- it's okay to point someone to the appropriate documentation, and maybe the section. That amounts to reducing an O(n) or O(log(n)) search to O(1) time. For complex questions -- defined as those which involve multiple, inter-dependent answers -- sending someone to the documentation is no more efficient than telling someone to use a brute-force approach to finding a longest common substring. It forces them to use an O(n!) process when you could give them an O(1) process again.

Yes, people who get examples can become helpless, cut-and-paste coders, but that's not your problem for two reasons:

One, you have neither the power nor the mandate to turn everyone into a good programmer. The people who want to be good will go to the documentation on their own, and explore new combinations based on your memoized example. The ones who don't care won't read the documentation anyway. There's nothing you, I, or anyone else can do about that, and none of us want to live in a world where someone could do something about it.

Two, the difference between saying "here's an example" and saying "use CGI.pm" is one of degree, not one of concept. When you get right down to it, using modules is just a disciplined form of cut-and-paste coding. If you look at any standard argument for using CGI.pm, you'll find what amounts to an argument not to go back to the underlying documentation (HTTP, MIME, CGI, HTML, CSS, etc) for onself: 'Someone else has already explored the space and memoized a set of solutions, so "use Them.pm"'.