根据我使用多分支管道的经验，唯一的缺点是你不能在Jenkins主页上看到最后的成功/失败/持续时间列。它们只是在Jenkins首页上显示“NA”，因为它在技术上是子作业的“文件夹”。
除此之外，我想不出使用多分支的其他“缺点”。
我不同意另一个答案....这种情况是multibranch发送“任何”分支的更改。这不一定是真的。如果Jenkinsfile存在于随机特性分支上，但该分支未在管道中定义，那么您可以使用典型的if/else条件来对它做任何事情。

例如：

node {
  checkout scm
  def workspace = pwd()

  if (env.BRANCH_NAME == 'master') {
    stage ('Some Stage 1 for master') {
      sh 'do something'
    }
    stage ('Another Stage for Master') {
      sh 'do something else here'
    }
  }

  else if (env.BRANCH_NAME == 'stage') {
    stage ('Some stage branch step') {
      sh 'do something'
    }
    stage ('Deploy to stage target') {
      sh 'do something else'
    }
  }

  else {
    sh 'echo "Branch not applicable to Jenkins... do nothing"'
  }
}

如果你的Jenkins作业处理单个git仓库，那么多分支管道工作得很好。另一方面，管道作业可以是仓库中立和分支中立的，并且在使用单个Jenkins作业处理多个git仓库时非常灵活。
例如，假设您有来自repo-1的artifact-1，来自repo-2的artifact-2，以及来自repo-3的集成测试。并且artifact-2依赖于artifact-1。Jenkins作业必须构建artifact-1，然后构建artifact-2，最后从repo-3运行集成测试。假设您的代码更改转到repo-1的feature-1分支，并且feature-1分支用于repo-3中的新测试。在本例中，Jenkins作业为artifact-1构建feature-1，然后从repo-2使用'dev'分支作为默认分支（如果repo-2中未检测到feature-1），并从repo-3运行'feature-1'进行新的集成测试。正如您所看到的，该作业与三个git存储库配合良好。在此设置中，repo-neutral/branch-neutral pipeline作业是理想的。

在CI/CD情况下，可能不希望将每个分支都发送到目标环境。使用管道并指定单个分支将允许您进行筛选，并仅将/master发送到分段或生产环境。多分支对于将任何分支上的任何更改专门发送到测试环境非常有用。
另一方面，如果QA/AutomatedTesting过程足够彻底，则将任何分支发送到生产的风险都可以接受。

如果你还在开发你的流程，简单管道还有一个额外的好处，那就是支持参数化项目。这个特性对于在jenkins gui中开发声明性管道很有用，使用参数来控制你要针对的分支/仓库。

有很多CI/CD任务与GIT/源代码无关。例如，准备docker镜像，提供不同类型的测试环境，清理等。对于这种情况，您不需要使用多分支方法。它只会使事情变得更加复杂。
使用多分支插件进行源代码处理有两个好处：
1.所有分支中的源代码应该以相同的方式处理。

1. Jenkinsfile描述了包含在源代码树中的管道。否则，使用多分支插件会变得很棘手。
   当然，你可以根据分支/pr来改变管道的行为。但我认为这是一个不好的做法。不幸的是，我经常遇到这种做法，它看起来很难看，有时会在管道需要重大更新时导致问题。