I can't imagine that's the case on every change they make.
Me neither! Just some of them.
Actually a lot of them do appear to come with no such basis. For instance, it was recounted that Johan literally just up and decided one day to increase province count by an arbitrary number. This was one of the most dramatic changes to the game, but the devs themselves say they had no such meetings when this decision was made.
Other times we have been given inconsistent rationales and reasons for changes.
Certainly many, many of the mechanisms look like giant kludges. Relations, after all, are suppose to be a measure of how likely another country is to go along with your policy goals ... but they are riddled with giant -100 modifiers and we just tacked a favor system on that is poorly integrated with relations because they do not appear to have internal design consistency.
Bolded the key word there. Any time that it isn't glaringly obvious why a given change was made and a dev doesn't take the time to outline the rationale, it
appears on the outside to be a change with no basis. Assuming that's actually what happens is basically accepting that the devs come in to work in the morning and just randomly muck up stuff in the game for no reason.
This is not how people approach their career works.
The story of adding provinces to the game is just that -- a story. You and I weren't actually present when it happened; we have a few sentences from Wiz about it that were communicated to us primarily to entertain. Why would he stop and go into several paragraphs detailing all their internal communications? And why would you assume that Johan requested these map changes without doing any consideration as to whether it would be consistent with EU4's design goals?
Also giant kludges are pretty much par for the course in complex software projects, especially those with frequent changes like this one. To avoid or eliminate kludges in something like this you'd have to perform substantial re-engineering every time you wanted to introduce something new. If Paradox did that, we'd get half as much DLC for twice the price with the same feature set. And that's probably an optimistic estimate.
What makes you believe this? The evidence we have opposes this belief. Namely, multiple mechanics function in conflict to developer statements, and more still you see changes that are at odds with other changes/reasoning given for changes (also, if the meetings happened and were executed well, we wouldn't have inaccurate/wrong/misleading patch notes for more major patches than not

). A few of those have been covered in this thread, so I don't want to beat a horse, but we have no reason to believe that criteria is first set in such meetings, then applied consistently to the design/implementation of the game's mechanics.
See above. It is extremely naive to assume that a developer makes changes to a game essentially randomly. Even amateurs tend to avoid this kind of behavior.
I have worked on a game project before (as the lead). Specifically a multiplayer strategy game that had a forum. I've been on the other side of this.
I've made changes to the game that I believed were consistent with my design goals, and I've run into loud player outcry as a result. Sometimes it was because their interpretation of my goals wasn't in line with my actual goals for various reasons. Sometimes it was because I made mistakes -- the implementation failed to live up to the concept, or there were unintended side-effects that themselves were indeed in contradiction with my goals. Oftentimes you're forced to make trade-offs, holding your nose and implementing something that isn't really what you wanted to do, but it's better than the alternatives you were able to come up with or investigate for different reasons. These latter ones are often quick fixes, and you fully intend to revisit the issue and address it later, but then priorities are changed and this thing that was supposed to be a temporary patch becomes an annoyingly integral part of the game for a year.
This stuff isn't easy. It's hard to do even if you're really, really good at it and blessed with a large budget and team. People will make mistakes, or they will do things that
appear to be mistakes because you don't have the full information to perform a proper evaluation of the choices made. And they will often disagree about whether or not something is good or bad for a game.
For example, I expect the devs don't see your issue with the Incans to be a serious problem because it's only the most skilled and effective players that will likely encounter such lengthy downtimes. Less skilled players won't unite so quickly and so are much less likely to be sitting around for decades on speed 5 waiting for the Europeans to arrive. Strictly speaking, there are far more less skilled players than there are players at your level. Therefore, internal priorities will declare this mostly a non-issue.
Inability to survive European invasion afterward might be a problem (since the general audience would encounter it as well), but it's a bigger one as it starts to get into a lot of other systems that affect a lot of other things, so it would need to be tackled very carefully (in concert with stuff like naval revamps, which we already know is in the queue somewhere, and accompanying AI rewriting that might allow for the long-desired mechanic of forcing smaller armies shipped around the world).
Finally, there's also the reality that people change their minds over time. A design goal in 2014 may now be seen as undesirable by the same team in 2016. This could happen for a lot of reasons -- talking to players, experiences with the game over time, evolution of personal taste, new ideas making the rounds in the game designer community, and more.
As an aside, I'm not sure I've ever seen large and detailed patch notes for any piece of software that are 100% accurate. It doesn't really matter how dedicated you are, some things will slip when you're transcribing that many things. Even if you're using change management software to record everything and have very disciplined developers.
It's perfectly fine to call out inaccuracies and inconsistencies. It's a good thing to offer analysis of changes; this does any design team a good service. But try to avoid working from an assumption of incompetence and randomness on the part of the design team. That doesn't help anybody, and it's very rarely accurate. Even for projects that go totally south.