Why does spring initializr make a project inheriting from spring-boot-starter-parent instead of using spring-boot-dependencies

Question

When a project is created with spring initalizr then pom.xml inherits from spring-boot-starter-parent:

<?xml version="1.0" encoding="UTF-8"?>
<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
         xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 https://maven.apache.org/xsd/maven-4.0.0.xsd">
    <modelVersion>4.0.0</modelVersion>
    <parent>
        <groupId>org.springframework.boot</groupId>
        <artifactId>spring-boot-starter-parent</artifactId>
        <version>3.1.3</version>
        <relativePath/> <!-- lookup parent from repository -->
    </parent>
    <groupId>com.example</groupId>
    <artifactId>demo</artifactId>
    <version>0.0.1-SNAPSHOT</version>
    <name>demo</name>

This seems to be less flexible comparing to specifying spring-boot-dependencies in <dependencyManagement/>, for if we need to use the generated structure as a child module of multi-module project, or use company-wide parent we need to move BOM into mentioned section:

<dependencyManagement>
    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-dependencies</artifactId>
            <version>${spring-boot.version}</version>
            <type>pom</type>
            <scope>import</scope>
        </dependency>
    </dependencies>
</dependencyManagement>

Is there any specific reason for usage of spring-boot-starter-parent as parent instead of declaring <dependencyManagement/> section immediately at creation time?

Answer 1

Someones have voted to close the Q, insisting it is opinion based, however, it is not.

The existence of plugin configurations (BTW, at first glance the purpose of those configurations was to fix some "glitches" of maven plugins, however, some of those configurations are not required anymore, for example: https://github.com/JetBrains/kotlin/pull/1501) is not the only difference between:

<parent>
 <groupId>org.springframework.boot</groupId>
 <artifactId>spring-boot-starter-parent</artifactId>
 <version>3.1.3</version>
 <relativePath/> <!-- lookup parent from repository -->
</parent>

and

<dependencyManagement>
 <dependencies>
  <dependency>
   <groupId>org.springframework.boot</groupId>
   <artifactId>spring-boot-dependencies</artifactId>
   <version>${spring-boot.version}</version>
   <type>pom</type>
   <scope>import</scope>
  </dependency>
 </dependencies>
</dependencyManagement>

In the first case, maven project inherits dependencyManagement via parent-child relationship and so, since spring-boot team defines dependency versions via properties section, the child project may override dependency versions via properties section as well, e.g. if our goal is to change the version of spring-framework without changing the version of spring-boot we may define something like:

<properties>
 <spring-framework.version>6.0.15</spring-framework.version>
</properties>

which, obviously won't work in case of second configuration - there maven just imports dependencyManagement section from independent BoM.

That is not clear what approach is "more flexible" (we prefer to stay clear of both), however they are different from dependency management perspective as well.