If the used hash function is based on the Merkle-Damgård construction, then it is vulnerable to a length extension attack [1]. That means if an attacker knows a hash of the form H(pepper || salt || password), then the attacker can generate more hashes H(pepper || salt || password || password_extension) by only knowing the combined length of pepper, salt and password but without knowing any of the values. That does not help breaking the password but you still have an attack point in your system. Maybe someone makes a really bad decision and decides to reuse the password hash for something it really should not be used. Also note that with this construction you can trivially find collisions for different pepper, salt and password, they just have to yield the same string when concatenated.
Okay, but the suggestion was not to just concatenate everything but involved hashing parts before further concatenating and hashing them again. The length extension attack will still apply, you could for example use it on H(pepper || password) in H(salt || H(pepper || password)). Is this useful? Where would you get the length of and a hash for pepper || password from? I don't know but why would you risk that someone figures out how to do and abuse it if there are alternatives? And last but not least constructions like H1(H2(message)) or H1(message) || H2(message) may look innocent but they are not and they may weaken your system. See for example this Cryptography Stack Exchange question [2] or the answer by ircmaxell on this Stack Overflow question [3].
[1] https://en.wikipedia.org/wiki/Length_extension_attack
[2] http://crypto.stackexchange.com/questions/270/guarding-again...
[3] http://stackoverflow.com/questions/348109/is-double-hashing-...