Unfortunately, there is no setting, and there are not currently any plans for such a feature. If anything, we've been moving in the opposite direction. Because AtoM includes a number of web-based forms, user added content that can be interpreted as HTML was previously breaking form layout when people tried to format the text in various ways. I think if you try manually adding a <p> tag to an AtoM field now, it will behave much as this email / forum post will - it will display as raw input, rather than trying to render the content now. So if we were to have such a setting in the future, then your paragraph tags would be visible to users without further work to attempt to identify and hide them on the fly.
We did go down that road previously with the extent and medium field, allowing supported EAD 2002 nested extent elements to be imported, and remain hidden in the user interface on import, as a way of trying to reconcile the structured data options available in EAD 2002 for this data against the single field approach in AtoM, based on the loose requirements of ISAD(G). It was a bit of a nightmare to maintain, and caused all sorts of unexpected knock-off effects that would make me personally wary to go down that route again. Ultimately, AtoM is a database-driven web application for archival management that can support basic XML import and export, not an XML focused application or authoring and management tool.
To help address formatting requests, we did also add markdown support - plus there are some long-standing helpers in the fields, so manually adding 2 carriage returns should on save properly render. We could in the future extend our XML support by trying to translate markdown formatting for emphasis (strong; italics; etc) into equivalent formatting elements in the EAD or EAC generated on export, and vice versa. I believe at present there are a few elements supported like this on import, but not export, so development would be required to pursue this further.
In the meantime, I only have a partial answer for you so far, but it does seem that there is some generic code that attempts to deal with elements such as <p> on import, and convert it.... into two newlines! See:
I'm yet not sure why this isn't doing what's expected in the EAC bioghist element - it could be that there isn't currently code specifically looking for <p> in <bioghist>, or a bug, etc. I'll have to see if we can dig any farther.
In the meantime, you could try changing line #487 in that file from "\n\n" to something like "\n\n\n" to see if it makes a difference? I would be curious to hear the result!