but since the new request is different we need to use another component so that there is less chance for users to misunderstand
Stepping into the specifics of development for a brief moment: this does not logically follow.
You don't give the baby a new name because it needs a haircut and because it would be confusing for people to use the original name to refer to a baby with a different haircut. Or, more comically if you're into cars, Porsche has in no way been forced to come up with brand new designs for the 911 just because the engine specs have been upgraded over literal decades. They look the same and no one's getting confused over that.
Based on the quoted snippet, it sounds like you're arguing that changes must be dramatic enough to be blatantly noticeable so as to avoid confusion as to why something would otherwise be subtly different from its previous incarnation.
There are cases where this is a relevant consideration. For example if a company rebrands itself you want to make it visually obvious that this is a new company; even if most of the content remains unchanged.
However, the context of your problem does not seem to warrant explicitly branding itself as different and new.
However tech team including project manager insisted to use the previous UI component and they think it is sufficient to show information to users.
I'm hard-pressed to believe that your entire team is somehow glossing over the existence of the change request. Given the amount of communication there has been on this topic between you, its existence should be blindingly obvious to every involved party; so I'm looking for alternate explanations for this disagreement.
If this is a matter of the entire team being unaware of this change request, that's a much bigger organisational issue than we can solve based on your current question.
Is it possible that there is some confusion here where they think you're saying "we must reuse this exact component" but you in fact mean to say "we can take inspiration from this existing component when redesigning our component"; and similarly that you think they're saying "we should keep the original component exactly as it is", but they in fact mean to say "we should stick with the overall style of the original component when we add some more fields to it"?
Because this would render the disagreement makes much more sense: you want to innovate the style and they don't. Here, you're actually talking about the same topic; whereas in your original description of the disagreement it seems like you're on completely different tracks.
Things like this happened so many times, and every time the client went back to us and wanted a better UI for user. (Turned out I was right every time)
it seems like nobody believes that I am right.
Documentatively, what does the customer do to indicate that they want to make some changes? Is this officially registered? Do they tell you verbally during a meeting?
There is something at odds here. If you are not intended to be the source of the customer's wishes (since your input is allegedly being dismissed); then who is responsible for that? Are they informed of the requested changes? Should they be kept in the loop more? How did they weigh into the conversation where your wireframe was being dismissed by the rest of the team?
I cannot conclude who is to blame here. It's possible that the company is skipping an important administrative step in this process; but it is just as possible that you (in your well-intended eagerness to work for the customer) end up bypassing the necessary administrative steps that the company expects you to take.
For example, the customer may have mentioned this change to you during a meeting, expecting that you would take it up the chain to the PO (or whoever's responsibility it is to coordinate the customer's wishes), but you simply started working on this without keeping others in the loop. This is just an example, since you didn't give us any specifics on how this change was requested.
So how do you approach this kind of disagreement?
When you suspect that you and your team members are disagreeing on a basic principle, it's often hard (if not impossible) for one member to singlehandedly figure out who has misunderstood whom. You need to sit together on this to work through the confusion.
In this case, you could've brought an actual record of the customer requesting the changes that you claim your wireframe incorporates. When and if your team members dispute that claim, don't just balk at it. Ask them for concrete points on which they disagree. What part of your work does not comply with the request of the customer? Could you have achieved the same goal with less effort? How would they go about it?
Based on their answer, both you and them can slowly build up an understanding of each other's understanding, and eventually you will hit upon the key element which you didn't agree on.
Once you know what that key element is; the next step is looking for confirmation on what the correct interpretation is. This can come from documentation (e.g. analysis), or could require direct input from the customer when there is no clear answer available.