Six years into building WordPress plugins for clients, every single one had a subtly different structure depending on who wrote it and when, a folder layout that made sense to whoever built it at the time but rarely to the other person picking it up later. Onboarding either of us onto the other's project meant relearning conventions each time, where does admin-specific code live, is there a separate file for shortcodes or are they mixed in with everything else, is there an uninstall routine at all or does deactivating just leave options sitting in the database indefinitely.
We picked a well-documented open-source plugin boilerplate as our new starting point and have used it on every custom plugin since. Consistent folder structure for admin versus public-facing code, a clear separation that used to vary project to project, consistent naming conventions for classes and functions, and a proper uninstall routine included by default instead of forgotten, something we'd genuinely skipped on more than one older plugin, leaving orphaned options in a client's database indefinitely after a plugin was removed.
The upfront cost was an afternoon spent reading through someone else's opinionated structure and adjusting some habits, we'd developed our own loose conventions over the years and a few of them didn't match the boilerplate's choices, prefixing function names differently, organizing includes in a slightly different order. Adjusting to someone else's opinions after years of our own took a bit of ego-swallowing, honestly, but the boilerplate's choices were reasonable enough that arguing for our old habits instead would have been stubbornness rather than a real technical objection.
The payoff has been every plugin since feeling immediately familiar regardless of which of us wrote the first version, we tested this directly a few months in when one of us needed to add a feature to a plugin the other had started from scratch, and found the relevant file within a minute purely from knowing the boilerplate's structure, no need to ask where anything lived.
One thing we've had to watch for: the boilerplate includes some scaffolding, a full settings page template, a widget class stub, that a given plugin doesn't always need, and it would be easy to ship all of it unused out of sheer inertia. We've made a habit of deleting the pieces a specific plugin doesn't use rather than leaving dead scaffolding in place, since an unused settings page still shows up in the WordPress admin menu confusing a client, and dead code left in a plugin is exactly the kind of thing that made our old un-standardized plugins hard to trust at a glance in the first place.
We also documented a short internal guide, maybe a page, covering the handful of places where we deviate from the boilerplate's defaults on purpose, a specific text domain naming convention we prefer, a slightly different approach to enqueueing admin assets that fits how our client sites are typically hosted. Writing that guide down, rather than carrying the deviations as unwritten habit, means a future version of either of us, or a contractor helping out during a busy stretch, can tell the difference between "this is the boilerplate's convention" and "this is a deliberate choice we made and why," which matters more than it sounds like it should when reading someone else's code six months later.