1. Has this taught me anything new and valuable? (If not, move on quickly)

Yes - The whole suggested lifecycle of an ideal "specification by example" team sounds awesome, but the biggest takeaway for me is that ideally you should derive your project's scope from the business goals. I suppose I kind of already knew that from other things I've read, but for whatever reason the way it's described in chapter 2 really clicked with me. The business shouldn't be designing the software - they should be telling you what their business goals are and then you collaboratively work out how to actually do that. I've never worked on a project where that was attempted, so it would be cool to read about case studies where it was done (I believe that later chapters in the book have this).
2. How can I apply insights from this article today? (Wait and I’ll forget)

My current project is in maintenance mode and no more money is being spent on new features, but I may get a chance to work on another project soon. Even for my bug-fix mode project, if anything does come up I'll question why the business is asking me to do something so I can potentially solve their problem in a better way that what they have suggested. On the other project where new features are going to be added I will do the same, assuming I can identify who the stakeholders are :)

3. When have I applied the ideas from this post? Where have I not, but could have? (What was the difference?)

I have attempted to apply this on another project which was trying to be "agile", but in the end all of the requirements were enforced on us and we had no say in the requirements - we just had to implement what we were given as-is.

Other than that, I have questioned requirements on occasion especially where I could see a much better way of doing something, but usually I haven't delved too deeply into the business reasons for a request as for project work usually I am given a requirements document and that's the end of the discussion.