It might be the case that you really like the patch-based workflow, or perhaps you simply want to collaborate on a project where maintainers insist on it. Either way, it makes sense to set up a workflow that works for you.

Dealing with patches is never fun, but it can be easy! I use notmuch mail and its Emacs interface notmuch-emacs to read most of my email, and the vast majority of projects I interact with use git for version control.

(defun apply-open-guix-patches ()
  "Apply all opened patches to my guix source checkout."
  (interactive)
  (notmuch-show-pipe-message t "git -C ~/src/guix am --3way --signoff"))

You will most likely want to customize the command passed to notmuch-show-pipe-message. You could parse both the mailing list header and other parts of the email to dynamically build the command string: notmuch-show-get-subject could be used to select a specific branch and/or worktree to apply your patches to. An integration with project.el or projectile would allow easy selection of which 'project' to apply your patches to.

A patch-based workflow via email might feel antiquated in $CURRENT_YEAR, yet being able to understand, adapt and compose the smaller building blocks tools you depend on is a positive quality that extends to Emacs, git and email in general.