There are some great answers here from a pure security perspective. The self-XSS angle is absolutely correct, even if the top one related to that didn't explicitly make the connection it implies.
Being, essentially, that if people can get tricked into dropping self-XSS code into the dev console, why would you expect them not to not get tricked into dropping into some input element in your UI?
Some other answers tie that together into how this can create broader issues when it (imo, inevitably, if someone gets tricked into self-XSSing) leads to account compromises.
I think those are probably the top, immediate reasons. But I'd still like to address this from another angle:
Development Practices: Implications of Allowing Self-XSS
Let's say a user can store some data in a web app. I'm now only
talking about that sort of data the user can THEMSELVES view, not that
is intended to be viewed by other users of the webapp.
The problem with your supposition here is that it assumes that you don't prevent XSS on all output of user provided data as a default practice: ideally as the default output mechanism of the class or function used to retrieve and output data, with any deviation requiring a specific parameter to select the different output filtering method.
If you don't have your application coded in such a way that the default method of output prevents XSS (and different output targets such as attributes versus elements require different methodologies for what is and isn't allowed, hence 'default'), and it requires more effort (not less) to target output to allow (hopefully whitelisted, "purified") something to go through as native HTML/etc...
How sure are you that you aren't going to have an accident where some reflection of user data back to the web doesn't allow XSS outside of just "data the user can THEMSELVES view"?
Because mistakes happen. People forget steps when writing code. Failures occur in training where key points or even topics get missed. Some people do not "RTFM": even developers. Your application architecture/framework should be all about making sure that the path of least resistance when writing code is always the safest outcome, not the least safe outcome.
Allowing XSS to potentially occur based on user input should require a positive action, an explicit choice by the developer in relation to each place this might occur, not simply be the basic, default outcome of pulling stored user data and reflecting it back out. If your code is not being written like this, where it prevents XSS by default and requires an override parameter of some kind to disable this output purifying, then it's a sign that you need to re-evaluate your process.