When logic for a cross-cutting concern is mixed with logic for a different concern (either a core concern or another cross-cutting concern), it is known as tangling because the logic for disparate concerns is tangled together.
An implementation that is tangled is likely in violation of the separation of concerns principle and tends to suffer from low cohesion. Mixing concerns increases the complexity of the software and reduces its quality. It lowers maintainability because changes to both core and cross-cutting concerns are made more difficult.
When designing the solution for a cross-cutting concern, we want to avoid tangling. Part of accomplishing that is to make the logic for the cross-cutting concern loosely coupled with the code that needs it. Cross-cutting concerns should not be tightly coupled with other concerns so that all concerns can be easily maintained and modified.
Another principle that we should follow in order to avoid a tangled solution is the Single Responsibility Principle (SRP). A class should be responsible for one thing and do that one thing well. If it is responsible for a core concern, such as some piece of business functionality, it should not also be responsible for implementing a cross-cutting concern. A responsibility is a reason to change and a class should have only one reason to change.
A class responsible for a core concern should not need to be modified if we want to change the implementation of a cross-cutting concern that it uses. Similarly, the implementation of a cross-cutting concern should not need to be modified if we need to change the implementation of a class that uses it.
Avoiding a tangled solution also allows us to adhere to the Open/Closed Principle (OCP), which states that software components should be open for extension but closed for modification. When we want to add cross-cutting concerns to business functionality, we should have the ability to do so by extending the component with new code without being required to modify the existing business logic.