Ten years of bad programming may make you experienced, but it doesn't make you good.
I would question the big-picture awareness of any competent developer who refused this section of an interview. How senior can you really be if you don't recognize why this section of the interview is being given?
(By the way I'm a huge fan of your app and have used it every week for years.)
Separately, how do you properly verify some library, tool, or vendor if you can't actually push it during evaluation?
How do you mentor more junior engineers if you don't know how to create working code?
And the reason everyone has to spend 30 minutes writing working code is because there is a depressing number of seemingly inflated resumes out there.
I would expect a really good design to consider the expected edge cases up-front, and take them into account. The goal cannot be a dogmatic "eliminate all edge cases" approach - because that can only become a self-defeating exercise in frustration. Instead the edge cases should become easier to detect and, as much as possible, not cascade. Debugging a subtle concurrency related timing issue or race condition is bad enough. Debugging the cascading failure and data loss due to a chain of them is a morale destroyer.
Understanding where these edge cases can crop up is important. Even more so, understanding why they appear, and how to address them, is the mark of a really good senior engineer.
For that reason I expect a senior to be able to still program. Senior engineers may not spend their time glazing at their editor, but I do expect any senior to spend plenty of their time with both code review and mentoring.
How would you identify these people if you don't ask for programming problems.
We interviewed some experienced people who did terrible in the in-person interview. So we tried giving experienced people a pre-interview question, that maybe took a couple of hours of focused effort. The idea was the people who couldn't do it great during that instant could sit down in their preferred environment and code something up and take their time.Some people did better with this. I personally hate pre-interview questions, so I argued against it but we still tried it.
I find the code review of bad code too easy, not persuasive. Is it a bad idea for a service to hand out ids that are memory locations of runtime structures, and take them back? Obviously, but a surprising number of people don't see that, including experienced people.