This is not related to autoconfigure which is just responsible for adding tags when the service class implements a given interface or extends a given class.

Here, you're registering your controllers as services using the PSR-4 based discovery, that basically means "this defines as much services as there are classes in this namespace/directory`.
Then, you're defining explicitly one of these service, which would have been auto-created by the PSR-4 discovery used just before. This means "this service is an exception, it is configured explicitly, don't auto-discover it".
By doing so, you're just overriding the previous (PSR-4 discovered) definition as if it does not exist. Thus there is no bug, you have to explicitly define the method calls for this service, there is no kind of inheritance between the first (PSR-4 discovered) service and the second (explicit) one.

i have done this with normal services (specially abstract ones), but is there a way for "AppBundle\Controller\Admin\Block\BlockController" to use "AppBundle\Controller\Admin\" as Parent?

What about parent:? https://symfony.com/doc/current/service_container/parent_services.html

parent does not work with _defaults

parent does work with _defaults, but you have to redefine the attributes that are defined in _defaults on the child service (it cannot inherit them). What breaks is:

AppBundle\Controller\Admin\Block\BlockController:
    parent: AppBundle\Controller\Admin\Block\

Because AppBundle\Controller\Admin\Block\ is not a service, it's one service per class found in this namespace.

Note that we maybe could do something about this:
Imagine the psr4 loader creates a FQCN.prototype private service, aliased to its FQCN so that things work the same, then a child def could have FQCN.prototype as parent and achieve what we're talking about here. WDYT? Would like to give it a try?

Makes sense to me, I will do!

For 3.3 the alternatives seems to create an abstract service extended by both

_defaults:
    autoconfigure: true

app.admin.abstract_controller:
    abstract: true
    public: true
    calls:
        - ['setLogger', ['@logger']]

AppBundle\Controller\Admin\:
    parent: app.admin.abstract_controller
    resource: '../../../src/AppBundle/Controller/Admin'
    tags: ['controller.service_arguments']

AppBundle\Controller\Admin\Block\BlockController:
    parent: app.admin.abstract_controller
    tags:
        - { name: controller.service_arguments }
        - { name: app.admin, group: site }

Or use _instanceof

_instanceof:
    Symfony\Bundle\FrameworkBundle\Controller\Controller: # better use your own base controller
        public: true
        tags: ['controller.service_arguments']
        calls:
             - ['setLogger', ['@logger']]

AppBundle\Controller\Admin\:
    resource: '../../../src/AppBundle/Controller/Admin'
 
AppBundle\Controller\Admin\Block\BlockController:
    tags:
        - { name: app.admin, group: site }

If its just about the logger, why not implementing Psr\Log\LoggerAwareInterface on services/controllers, that should log and create an _instanceof entry with it? Repeat for other ServiceAware Services/Controllers, e.g with your own ...AwareInterfaces. This way you also follow composition over inheritance. Or maybe I don't get your point...

@Basster It was just an example. Unfortunately, I try to refactor an lagacy app, so can't easily use interfaces. In my new app I use exactly this approach

See #23548

Closing as "won't implement". See experiment in #23548, which didn't go well enough :)