Overloaded methods for different types VS introducing new abstraction [closed]

In our code base we have entities called PaymentPeriod and BaselessPeriod. Both entities have start date and end date attributes, and are very familiar.

I have to create methods which does some date overlap checking for either of these entities depending on use case. The logic operates on start date and end date, and is identical for both entities. Here is an example

// PaymentPeriod
public static boolean doesOverlap(Benefit benefit, PaymentPeriod period) {
        return benefit.getBaselessPeriods().stream()
            .anyMatch(p -> hasSameStartDateAndEndDate(p, period));
}

// BaselessPeriod
public static boolean doesOverlap(Benefit benefit, BaselessPeriod period) {
        return benefit.getBaselessPeriods().stream()
            .anyMatch(p -> hasSameStartDateAndEndDate(p, period));
}

Much duplication, right? To minimize the duplication, I created new Period abstraction with following operations. I made entities to implement this interface (which they already did).

public interface Period {
        LocalDate getStartDate();
        LocalDate getEndDate();
}

Then I refactored those duplicate methods into more generic solution using the novel Period abstraction.

public static boolean doesOverlap(Benefit benefit, Period period) {
        return benefit.getBaselessPeriods().stream()
            .anyMatch(p -> hasSameStartDateAndEndDate(p, period));
}

However, my colleagues criticized the solution for introducing unfamiliar Period abstraction into established codebase. They told me it makes the method harder to grasp for some current and future developers with not strong OOP mindset. For me, this kind of factorization is bread and butter of OOP. How should I justify this new abstraction for my team? Or should we really ditch the solution because it doesn't align with project standards?