What this article could have meant is that putting the salt somewhere in the middle of the password supposedly increases the chance of being cracked by a dictionary attack or by brute force, because the rules to actually compose the same hash could not be implemented in your password cracker of choice. In reality, this is probably complete nonsense.
How does this work?
If you take a program like John the Ripper, you feed it with your password file like so (not the exact syntax):
Then you pass the format as a paramater that you think the hash is generated with. This can be:
md5(pass + salt)
md5(salt + pass)
md5(md5(pass) + md5(salt))
md5(pass + md5(salt))
md5(md5(...(salt + pass + salt)...))
John the Ripper comes with a premade set of about 16 subformats you get to choose from.
Putting the salt somewhere in the password would probably look like that:
md5(password.substring(0,4) + salt + password.substring(4,end))
So, using a technique like this requires you to write a small plugin for John at first, before you can start cracking (which shouldn't be a problem at all).
In addition, you, as an attacker, might have a list of hashes + salts of unknown origin and have no knowledge about the way how a hash is composed. This is rarely the case. If you, as an attacker, manage to extract hashes and salts from a databse, you probalby either find a way to extract the password hashing algorithm of the website or you just create a new account with a known password, extract the hash and salt for it and brute force the algorithm that was used to compose the final hash (which can be more or less challenging).
All in all, it is almost completely arbitraty where you put the salt and whether or not you iterate the hashing algorithm ten thousand times or not. This does NOT provide a significant amount of security.
If you want security, you can do way better by using a better hashing algorithm or bcrypt or something else that is computationally expensive.