You're absolutely right. Also, one thing I found surprising is that the analysis didn't seem to look for a relationship between project complexity & programmable logic. I've found that shelf/rack systems running 32/64-bit processors with backplane connectivity tend to have programmable logic; universal remotes with 4-bit uCs usually don't.
I recently did a project that was cost-constrained, and therefore I handled the rotary encoder input in firmware (single channel); had the # of channels been 32, or had the input been engine shaft speed instead of human input, another solution (perfectly suited for programmable logic) would have been needed... but then the project would have been in a different category of complexity.
One other datapoint that I've observed in my own experience; first-time design wins for programmable logic vendors are very often determined by the quality, cost & availability of their evaluation kits. You've got a lot of small product design groups with a single 50-year old engineer/tinkerer greybeard running the show, and he'll get a board, (re-)learn how to develop & apply programmable logic to the problem, and then in a few months that solution is designed into a product.
The market is dominated by high-cost, high-volume chips (defense, telecom, motion control, etc) but the long tail is populated by a bunch of tinkerers, dipping their collective toe into the PL pool. Probably not terribly interesting to logic suppliers, but people tend to move around...
Drones are, in essence, flying autonomous vehicles. Pros and cons surrounding drones today might well foreshadow the debate over the development of self-driving cars. In the context of a strongly regulated aviation industry, "self-flying" drones pose a fresh challenge. How safe is it to fly drones in different environments? Should drones be required for visual line of sight – as are piloted airplanes? Join EE Times' Junko Yoshida as she moderates a panel of drone experts.