Travis,
This isn't quite how editing in ArcGIS Pro works. Essentially each time you make an edit the system determines which databases are being referenced by that edit and it on-demand starts editing on those datasets. In the case of databases that support undo that edit session is left ongoing so that undo/redo/save & discard operations function as expected, but as a side effect schema editing operations such as add field are disabled until the edits are saved or discarded (much like ArcMap). To simplify the model of working against multiple databases simultaneously (& avoiding choosing a single database to edit, the way ArcMap does) as you make edits the set of databases being edited can gradually grow but save and discard is applied consistently to all at once. In cases of databases that do not support undo/redo the edits are saved automatically after the edit is made. In some cases (enterprise geodatabases) where some tables are undoable (versioned tables) and some are not (non-versioned tables) this can get quite complicated to explain. Another complicated example is branch versioned feature services where named versions can be edited with undo/redo but default cannot.
You do not need to disable editing on layers in order to perform schema edits (any such case would be a bug, probably an instance of some code leaking a lock or otherwise getting out of sync across threads). Currently if you undo your first edit save & discard are disabled but redo is enabled, which can be very confusing. This case will be addressed when 2.4 ships and discard will remain enabled (with save disabled) when you are still editing but do not have any outstanding edits. Clicking discard will disable redo, as the session is complete and release any locks needed to perform schema updates.
In short, the best way to consider ArcGIS Pro editing is that while things initially appear editable you are not Really editing the database until a command or tool attempts to perform a write, at which point the normal logic that ArcMap would execute in "Start Editing" (which may fail and is treated similarly to the edit itself failing) is executed automatically by Pro.
The checkboxes exposed in the Contents pane are purely to control which layers are allowed to edit through the tools, They do not directly effect edit locks as you might expect. For example, two layers referencing the same feature class may have different edibility check box states. Clearly editing one effects the other and certain functionality such as Geodatabase Topology validation may effect many feature classes in that database, so just because a layer is unchecked in the contents does not provide a strong guarantee against the underlying feature class from being modified. (Geoprocessing tools for example pay no heed of these settings). If you require a stronger guarantee it is best to manage it at the database permissions level not at the application level.
Thanks,
John Jones