While changing password, in my application I am performing only JS validation for password and confirm password field values. It is recommended to have server side validations. But confirm password serves purpose for user to be double sure about the password that it has typed. What is actually at risk if I do not send confirm password value at server and only save password value?
The rule is to control server side what actually matters for the server, and client side what matters for user. For example, if you want to allow only certain characters in password and a maximum length, this should be controlled server side. If you just want to be sure that the user knows what he/she has just typed, client side controls are fine.
Some controls can be done twice, because what matters for the server is the data, but what matters for user is to be warned of an error as soon as possible. For example it is fine to first control the validity of a field client side as soon as the field has been typed in to immediately warn the user, and then control it server side when the form is submitted.
Depends on what you're doing with it.
If you're only validating that password1 and password2 are identical, then server or client side is fine.
But back-end password validation and sanitization is a requirement.
While your JS validation is fine for manually submitted requests, bad actors don't care about or use your form except to read where to POST their brute force attacks.
failure to sanitize the password confirmation input can leave you open to a number of problems such as SQL injection.
Example: someone writes a script to submit your password reset or account creation form and appends
; DELETE * FROM USERS WHERE 1;
Failure to validate that causes your users table to be lost.
For a decent introduction on the various things you should protect yourself against, see: https://www.owasp.org/index.php/Data_Validation