I love Cypress overall, but wouldn't advocate using Cypress commands unless you are doing something weird.

Their examples show using Cypress commands for pedestrian things like "log in to app" but there is no need to get all Cypress-specific for things like that.

Instead, we typically write "test helper" objects for that, which are conceptually similar to the Page Objects pattern from the Selenium era. So like:

    class GroupUiTester {
        get groupChooser() {
            return cy.get('#group-chooser-button');
        }
    }

Then, in your test, you can just be like:

    tester.groupChooser.click();

That is kind of simplified, but even that would be useful if you had dozens of tests interacting with that group chooser element. (Especially since, unlike string-based "cy.get('.some-class.whatever')" it will all auto-complete in any decent editor.)

An example of "doing something weird" where we do use Cypress.Commands is like:

    Cypress.Commands.add('disableDefaultLocalStorageClearing', () => {
        Cypress['LocalStorage'].clear =
            SUBSTITUTE_CYPRESS_CLEAR_LOCAL_STORAGE_FUNCTION;
    });

We do that because the local storage clearing breaks a third party lib we use for a few tests. But that is something you can't just do with the regular Cypress/DOM API, so it is a good candidate for using Cypress "commands".

we have extensive Page Objects which let us re use code everywhere. i’m not a huge fan of cypress commands because they pollute a public prototype and i don’t like modifiying those

Ditto. It is really easy to write re-usable code for Cypress tests in plain TypeScript/JavaScript, and just directly import the file.

    x.usernameField.type('Joe User');
    x.passwordField.type('$ecureBR0');
    x.enterWrongCaptcha();
    cy.get('.err-captcha-fail').should('be.visible');

Basically, I think all the code to locate UI elements and perform common interactions with them should be in re-usable utility code, so that the actual tests can focus on just testing what they test.

I don't think the Cypress docs probably do a great job emphasizing how easy this is (especially since they go out of their way to de-emphasize the 'page objects' pattern, but without offering much in the way of a replacement).

Yes, I'll echo my disagreement with the Cypress advice against the page object pattern - the advantage was always that the logic to get the element could be updated in a single place, and that applies as much whether that code is 3-5 lines of webdriver code or one line of cypress code.

100% this is the model we follow. no dom in tests helps a lot. the cypress docs don’t make any sense here

Yeah, "no DOM in tests" is actually a pretty good mantra.

Code that is just inspecting the DOM to find elements, or to do stuff to them that is just working up to the state where you can actually test something, should be in some shared object/library, but that is as easy as:

    import { Whatever } from '/foo/bar';

Having that kind of code outside of the test probably makes the introductory "test hello world" example more complicated, but I think it's definitely a good practice in the real world, and isn't documented well.