It is not technical debt if there is no explicit decision, or it is the gradual and continuous bitrot that all codebases suffer. I usually refer to this as cruft and while good design and writing code to optimise for readability / understandability reduce the rate that cruft accumulates, it cannot be stopped due to the nature of software. The best practice I have found to fight cruft is many small refactorings and cleanups as part of every piece of work I deliver. This strategy is outlined in https://ronjeffries.com/xprog/articles/refactoring-not-on-th....

One point to note from your introduction was the following statement: I often find unit tests are hard to read, and especially harder to quickly identify what are the important pieces, or even what the test is testing about

Have you considered pairing with others in your team or using group code reviews to see if there is a style or understanding gap? This may be far more effective than trying to get people to use a novel unit testing framework with little or no real longevity.

The more you know the more you will come to understand you don't know much; that is both good and bad (Dunning Kruger vs Imposter Syndrome).

Every time you think you are the best in the room, look around and ask yourself are you overestimating your knowledge. If you are still the best in the room, maybe it is time to find a room with smarter people.

Not every solution requires code / technology.

The best code is easy to read and even easier to delete.

Give your code to the most junior member of your team - if they struggle with it you need to make it simpler.

There are many many lessons like these around - the single most important one - always be open to new ideas no matter how much they oppose your current beliefs; strong opinions, weakly held.