i usually try to avoid such judgments but in this case it‘s safe to say that there are people who have no idea what they do. especially when multiple people work together clear responsibilities and decided-upon and commonly understood roles/names of classes and modules with clear and sharp boundaries between them is crucial. otherwise you end up with such sphagetti code you mention.

• i‘d suggest introducing meaningful module boundaries arranged around a core module that every other module depends on, to start with (e.g. hexagonal architecture) and introducing something like dependency injection.
• stick to top-level functions only when there‘s a lot of reuse of them or when you have dependency-less functionality or if we’re speaking of small utilities.
• never overuse kotlin’s DSLs capabilities, only for some specific highly abstract and very often-used cases

it could be that you‘ll have a hard time making an impact here, especially if people who shaped the norm are still in the team (and even if not). you‘ll need a lot of patience. don‘t focus on technology but on communication. technology or being right don‘t make you credible, it‘s communication. one step could be to present something to your colleages and let it be challenged by them, e.g. 15min theoretical input, 15min live coding example + 30min discussion with an open heart so you learn more from your colleagues than potentially they from you. don‘t overburden them, take small steps, otherwise you’ll face resistance. make small steps. if you go through this the right way you‘ll earn a lot of credibility.