Velocity is defined as "number of units of work completed in a certain interval". To implement a unit of work, you typically have an existing part of software and add some new code and/or change some existing code. When the existing part of software contains a lot of technical debt, and you have to deal with it to implement a change, one would expect to need more time to complete a unit of work. On the other hand, the creation of new technical debt happens often in expectation to need less time to complete a unit of work in the current sprint.
So what is measured here depends always on the team and the actual code base (and probably the whole organization around it). There is nothing like an absolute "velocity of the team".
However, if your question is if there should be units of work dealing only with the removal of technical debt, and if they should be counted the same way as units-of-work for business requirements, then it should be obvious that mixing those two things up might give you a wrong picture about your team's real development speed. In fact, you have to decide for yourself if you want to measure how fast your team works, or how fast your team can deliver new business value. To my experience, most customers prefer to pay for the business value they get.