Why not store password in cookie?

Several points against the second model:

• Hashing the password should take a significant amount of time, so as to slow down brute forcing in the event of a database leak. Checking a password on every request is a waste of resources.
• Cookies can be vulnerable to XSS attacks, and having your password stolen is worse than having your session stolen (passwords aren't changed as often, and they tend to be reused on multiple sites).
• Cookies are generally stored unencrypted on the client.
• Sessions can't be easily invalidated, as it requires changing the password.
• It's completely incompatible with any Single Sign-On system (thanks @CBHacking)

Storing the password hash instead of the password isn't much better, you solve the performance problem but you're still potentially leaking the password hash to be brute forced, and you can't easily invalidate sessions, or even tell them apart in the case of a user with multiple concurrent sessions.

Completely agree with the previous answer. Here is a bit more context to help you assess the security of your solution.

Your first model is pretty much the typical session management with cookies. It supports all primary use-cases required of sessions.

Your second model is somewhat similar to Basic Auth, except that the authentication data could be exposed to the clients via leaking cookies (not setting the HTTPOnly flag). If the HTTPOnly flag is set you are very close to Basic Auth, sharing most of its properties: no reliable timeout, missing SSO support, leaking passwords, no multiple sessions, etc.

I put together a Web Authentication Guide to help decide which auth schemes fits best your use-cases. Check it out!