This is clearly opinion based but I think that you should see Ethereum as a big database and contracts as stored procedures.
Also as databases have transaction time constraints, contracts have fuel constraints that leads to a similar result wich is use less code as possible.
Most of the time you will have a program on top of it to compute data and display it. Most programs have the responsibility to check data they store and load in the database.
Stored procedures were used to harden the data coherence in relational models and even if they can be used to check data they were mainly used to make the data easier to query or store. But stored procedure are less and less used as they lead to systems that are difficult to update and maintain. Except for big systems or for systems with big legacy, you won't find stored procedures in relational databases today.
So, this is my own opinion, but you should probably try to make your Dapp JS code validate data it reads from and write to Ethereum.
The only difference is that with centralized systems, database is hidden so you don't expect users to query the database directly, otherwise you could provide an API that validates data.
In decentralized world, anyone has access to the raw data in the database. You can create an Api but anyone can bypass it. I think we have to deal with it. If someone crashes it's program because the code of the Dapp failed to check the data from your contract, you can help fixing and send advises, but you could also let it go because that's not your data and your contract that failed.
Also note that even if you implement validation in your contacts, none should trust it and double validating should be done. Yes we will have a lot of crappy contracts on the network and we should call them in a trustless way.
So your Dapp would have to check user input before storing it but also validate output from the contract as someone else could have called the contract without having the data correctly validated before.