If your just changing the control name and leaving the source alone, it would be just an issue of:
1) checking any actual queries that refer to that control name such as Forms!TheForm![Bad Control Name] just to make sure it changes there and also if you have any formulas in the queries (i.e. calculated fields, criteria, etc.)
2) in VBA do a search for [Bad Control Name] and set the scope to project wide. That should show you every where it is used.
3) you may need to check in SQL server tables to make sure there are not references to specific fields such as a settings table or other such, similar Richard's Dark Mode settings, etc.

Beyond that, if you really want to ensure you've covered all your bases, you could export all the objects as text files and then open those text files in any text editor and do a search for [Bad Control Name]. Or, if you're so inclined, use the methods Richard showed in the Developer courses to import them as text back into access and use the various search functions he has taught here.

Of course, in any option you choose, remember the most important thing: MAKE BACKUPS before you start.

What Donald said about exporting as text is especially useful if the control name is used in properties of other controls.

Do you mean "control source" or "control name"?  When you change a table field name, the "control source" will automatically update to the new field name, but the "control name" will stay the same.  For instance, if you change a bad field name like "@bad name" to "goodname" in the table, the control source on the form will automatically update to "goodname", but the control itself will have the same old name "@bad name" that you used before.  The form will likely still work.  It's up to you to decide whether this will affect you adversely going forward.

My advice is that if you want to correct bad names, then correct them ALL.  It's better not to go through the process of asking yourself, "Should I correct this?  Should I keep this?" for every single name, which would be much more time-consuming and frustrating.  Fix them all now so you won't have to worry about them ever.

Bad names can cause all kinds of problems and should be avoided whenever possible.  For example, if a control name has a space ("My Field"), Access automatically replaces it *internally* with an underscore.  It still shows "My Field" on the screen, but it will treat it as "My_Field".  Try creating another control with the name "My_Field", and it won't let you.  This is the kind of pesky little issues, one of plenty, that you don't want hanging around in your database, causing problems down the road.

Donald and Matt have the right idea. If you're only changing the control's Name property on an Access form or report, and leaving its Control Source pointed at the same SQL Server field, the underlying table and its "creative" field names are untouched.

What can break are any references to that control name: VBA, macros, query criteria such as Forms!MyForm!OldControlName, expressions in other controls, conditional formatting, validation rules, event properties, and so on. A project-wide search in VBA catches the code, but exporting the objects to text is the most thorough way to find property-level references too.

I would definitely make the Access control names clean and consistent, even if the SQL Server field names have to remain ugly for now. For example, a textbox bound to [2024 Plan] could be named Plan2024. Its Control Source stays [2024 Plan], but everywhere else in Access you refer to Plan2024. That makes your VBA and expressions much more readable and avoids constantly dealing with brackets, spaces, percent signs, and other nonsense.

I would be much more cautious about renaming the actual SQL Server columns. That can affect not only Access, but views, stored procedures, reports, imports/exports, other applications, and possibly systems you don't even know are using that database. Cleaning up the Access-side control names is a safe first step, provided you search for references and make a backup first.