Why the normal mode exist in BIP32
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)