I also had this feedback in queue to be submitted, so I guess I’ll drop it here. 
With many of the udpates that have been rolled out recently, UI friction seems to increase with each new release. For example, it will go from a 1-2 click process to a 3-4 click process.
This stuff is starting to accumulate.
Most of the updates seem solid to me. I understand why they’re being implemented. However, as someone who now spends a great deal of time in Coda, it feels to me as if there is a level of QA that is lacking from the feature development process.
If it doesn’t exist already, it would be nice to have a QA step in feature development that addresses UI friction, answering these types of questions:
- Are we adding or reducing UI friction?
- Are we adding or reducing clicks?
- Are we enabling the user to keep their hands on the keyboard, or requiring them to go to mouse?
- Are we establishing efficient keyboard patterns (both hands relatively stable or even one hand only), or are we requiring wide stretching of both hands? (especially important, the smaller the hands)
- Are we requiring the user to make large inefficient traversals across the monitor, or are we keeping monitor traversal tight and efficient (especially important, the larger the screen).
- Etc.
NEW USERS: For new users, the more UI modals they are forced to navigate through, the more labyrinthine and hard to remember the UX becomes. For as much as I use Coda, I have trouble remembering the exact sequence of UI menus I must click through to perform routine things. 
SUGGESTION: At the root of all UI sequences, include a search box that lets users type the exact thing they want to access, get the auto-complete menu, arrow down to their selection, and go straight to it. In the places where this already exists, I use it and love it. I suggest just basing the entire UI off that core module. On top of this, the UI can still be broken down into sub-menus and navigational signage as a way to increase on-boarding traction and new user education… and the universal UI search would allow new users to increase their own operational pace as they begin to learn the system. Best of both worlds.
Addressing this bucket of considerations before release is likely to cut down on much of your post-release overhead.
$.02.
EDIT: Hi @Angad, just saw your post re beta access for slash commands: 
In this new centralized way to discover a full list of objects you can insert, I would encourage you to not stop at insertable objects, but to also include the UI menu structure within this centralized searchable scheme, as outlined above.