When the planning is rushed, the effects are felt downstream. Project requirements keep changing, scope creeps in and there's a lot of stress and associated cost with reworking things and always starting over when you thought you were almost there.
When design is rushed, people can tell. Customers will feel something is off. Usability usually suffers.
When the code is rushed, bugs will likely happen. Developers will make compromises, they'll either introduce abstractions that aren't needed, or duplicate code everywhere. The result will be spaghetti code that will be hard to untangle later and a mountain of technical debt they'll have to pay down later anyway.
When testing is rushed, functional defects that prevent customers from using the product will sneak into production.
A lot of the times, it will feel like you don't need to plan in time for accessibility this sprint. Maybe you can ignore colour contrast on this form. What if you don't put labels on the form fields and just add some simple p tags because you're in a rush? And then you skip keyboard testing that form altogether.
It sounds like a perfect storm. And yet, when everything is rushed, it'll be people who suffer the consequences. For your users with disabilities, it's not a matter of the page looking as nice. It's a matter of not being able to use it altogether.
No colour contrast means they can't properly tell what the text next to each form field says. No proper form labels means no way they can use a screen reader to help them out. And because you skipped keyboard navigation, unless they use a mouse, they just cannot fill in that form. If only you planned time for accessibility this sprint.
But at least you have an excuse. You were in a rush. It's an easy excuse to reach for when things don't work.
You shouldn't wobble along, barely delivering features, double checking your triple checked work. Don't delay releases because you need more time.
Don't slow down. Hurry up!
Just don't rush!