It does make a difference because the attackers have comparable sophistication to the generators.
They don't have to brute force all 26^10 lowercase character sequences if they can instead look through 26^3 words in a dictionary. And optionally modifying those words to append "1!" to them, or capitalize the first character, or replace e with 3 or whatever doesn't take much.
Sure, but the attackers you want to consider are the ones who have generators that can match your minimum entropy to generate the password - assume their dictionary is no longer than yours, their set of punctuation doesn't have any characters yours doesn't, etc.
It depends whether you want to determine an upper bound or a lower bound on #guesses needed.
The article's approach has no assumptions and provides an upper bound. Your approach makes several assumptions and gives a lower bound IFF those assumptions hold.
The upper bound is useful for the general case: no attacker will be worse.
You're trying to account for more sophisticated attackers, which is great! It is however not clear (without further motivation) whether your attacker model is realistic. That is: will their be an attacker who knows this much about your password generation approach, but does not know more?
If no realistic attacker would know this much, your approach gives an overapproximation (real bound is higher). If, otoh, there is an attacker who knows more (eg, seed of the PRNG, or first characters, etc.), it'll be an underapproximation (real bound will be lower).
So, the difference is that the result of the first approach can directly be interpreted, while the result of your approach needs context.
The upper bound is a best case analysis. In the best case, I can choose “1” to be my password, and no one will ever guess it.
In the worst case, we assume that the attacker has done their home work and knows the algorithm by which the password was generated, but not the content of this particular password. So, knowing the algorithm, what can the attacker exploit that would help them discover the contents of this password in the shortest possible time?
I submit that the worst case analysis is really the only one we care about.
My point is that that is not the worst case. Example of a worse case: the attacker knows that + the first 2 characters of your password (real-life example).
The worst case would probably be something like "attacker knows hash, passwd algorithm, full state of machine at passwd generation time incl. random seed and all characters of the password but one". It is clearly far worse than your case, though I find your case more relevant than this one.
They don't have to brute force all 26^10 lowercase character sequences if they can instead look through 26^3 words in a dictionary. And optionally modifying those words to append "1!" to them, or capitalize the first character, or replace e with 3 or whatever doesn't take much.