Why the normal mode exist in BIP32 Suppose the BIP32 normal deviation is not safe enough. 

Suppose the xpub is deployed on the server, we assume it is public, then the leak of any derived private key is the leak of the parent private key, which means all the derived private and public key could be calculated.

Why this mode still exists, instead of using hardened mode as the default for all derive operation? 

The second Point I hope to clarify here, is that if there is only one bit in the path is hardened mode, say m/0'/0/0, then the derived address is a 'hardened' address (parent private key can not be derived from parent xpub + child private key), or we need every bit in the operation is in hardened mode?

The last question is what the "layer" means exactly in BIP32? 
(A) Per my understanding, if we have a master private key, any path (m/0/0, m/0'/0, m/1',m/1/2/3/) we used to derive the sub private key are the child address. If we use child address to derive again with any path (m/0/0, m/0'/1), then that is the second layer's address. 
or 
(B) if we have a master private key, use path (m/0') is the first layer. use path (m/0'/0) is the second layer?

What is the background and consideration for this design?
Hardened extended private keys break the extended public key derivation path, which is why unhardened key generation is still valuable.

I can provide an xpub key M/44’/0’/0’ to a webapp, which can then create fresh addresses without having access to any private keys.

For example, the following receiving keys (and related addresses) can be derived from M/44’/0’/0’


M/44’/0’/0’/0/0
M/44’/0’/0’/0/1
M/44’/0’/0’/0/2 


or following change keys (and addresses)


M/44’/0’/0’/1/0
M/44’/0’/0’/1/1
M/44’/0’/0’/1/2


The backend which has  m/44’/0’/0’ can derive all private xpriv keys to spend funds sent to addresses above, thereby never exposing any privatekeys to the userfacing webapp. However, a xpub key m/44’/0’ (hardened or not) cannot derive a hardened child xpub key m/44’/0’/0’.

The leak of a child private key does not expose parent keys. This would also require the xpub of the parent key pair and child index. Hardening prevents this exposure scenario. So for BIP44 the tradeoff is made at the account level (m/44’/0’/0’/) where the account parents are hardened but subsequent receiving and change keys are not.

Edited: Correction from Abdussamad (See comments)