I have tried his technique, but often find the opposite. With TDD, I often find the initial approach morphs significantly by the time I am finished. If I start with edge cases, I calcify the often-wrong initial approach.
I have found value in starting out with ‘thorns’ when the problem or structure is more clearly defined (because I’m adding a new class or function to an established system with clear patterns), but still disagree with it when starting anything significant.
Basically, I find proving edge cases a lot less interesting. You learn less. It’s comfortable and easy. For example, it’s often the first thing inexperienced TDD practicioners do. I’d rather jump down a few different critical paths and learn more quickly. If after a few successful tests, I decide removing thorns will make my code better (since I’ve established a way to approach the problem that feels right), I do that. But it is the backup, not the default.

And somehow, most of the time, the code I end up with is much simpler than the code I thought I would write.