It's not future requirement changes. Its that the conceptual model that you constructed for your original requirements doesn't accommodate a new requirement. Now if you construct a new conceptual model, you will have to modify the original code. It sometimes isn't feasible to do this to each new requirement especially if you suspect that the next new requirement will require yet another change to your conceptual model.
This can happen because the product roadmap changes (new PM, business changes, etc...)
Try writing UI for several different designers over the course of several years for several different iterations of features when there is no common design language.
Technical debt is about quality of code, not about changes in your conceptual model.
Lets say I had a warehouse that stored food, all stored neatly in its own section, each with the least frequently moved at the top where I need a forklift to access, and the most frequently used at the bottom where they are easy to access.
Someone orders too many boxes of rice, and there's no room in the rice section, but there's room on the lower shelves of the sauces so it gets stored there, and some are left on the floor, partially blocking forklift access.
The immediate problem of rice storage is solved, but every time I need sauces I have to grab the forklift, and it may take longer to get there and back because the route is blocked. This will persist until I refactor the warehouse so that there is more space to store the rice appropriately.
Now the manager decides we should be able to store refrigerated goods, and I have no refrigerators yet. The work to refactor the shelves to make room for the refrigerators is a conceptual change in how I use the warehouse, and not a direct consequence of how I've previously been storing goods. It's not tech debt.
Quality of your code can be affected because your conceptual model is muddy. Makes it more complex, harder to understand, harder to change. Makes you implement a requirement in two different ways.
This can happen because the product roadmap changes (new PM, business changes, etc...)
Try writing UI for several different designers over the course of several years for several different iterations of features when there is no common design language.