So in general I'm OK with using someone's words to illustrate a different point than they were originally making. But when I do this I prefer to explicitly state the original context and explain how I am reusing their work -- I try to point out what next information changes their idea, or where I disagree with them.
This helps in a few ways:
(1) Improves communication. When I use a quotation, some readers or listeners will know the whole context (or think they do). If I use it in a dissonant way and explicitly acknowledge the contradiction, that part of the audience will be more likely to trust that I have understood the person I am quoting. I won't be dismissed as ill-informed or as deliberately misinterpreting my sources.
For example I might say "yes, this part of the code is hard to read. Here is the deal. Knuth said that premature optimization was the root of all evil, and that you should understand what your code's slow parts are before you try to optimize it. But in this specific case I cannot easily modify my code after I deploy it and cannot easily test it on all kinds of real-world data I am expecting it to encounter pre-production, so we are defensively making this function very complex but also very performant on a diverse variety of inputs. That is why this function is so complicated up front."
(2) Improves understanding. For audience members who don't know the original context of the quotation, explaining it will help them learn something new. I thought the idea was interesting enough to quote, so probably it's worth at least a footnote about what the idea originally meant? Often if you beyond the one sentence there is a rich tapestry of prior context that is worth understanding. Humans spread our thoughts via the fragile web of written language and reiterating what has been said before can help reinforce those links and make our knowledge more durable.
For example I might say "You may have heard that Knuth said that premature optimization was the root of all evil. But it's worth reading the full three paragraphs from his paper, 'Structured Programming With Go To Statements' (1974), because he develops an entire nuanced argument that today is settled wisdom in software engineering practice. He argues that optimizations can be a great idea on the core inner loop of your program, even if they significantly hurt readability and maintainability. This still holds true with complex networked software -- you should always know what your system's slow inner loops are and you should be willing to go to unusual lengths to speed up the slowest parts. Here are some ways that distributed tracing can help with that…"
(3) Knowing what the original author was getting at seems to help me form my thoughts better.
In particular, reading the whole paper before I quote it helps me avoid re-discovering an idea that Knuth already had, and it helps me think more clearly about "given what he knew then and what I know now, what are the next logical steps? What can we learn?"
Overall the rule of thumb I use of reading/watching an entire work before quoting from it is … not for everyone. It can be exhausting. But it helps me learn and (I can't prove this) it feels like it improves the quality of discussion.