You need to remove the options and associated strings here as well
https://github.com/joomla/joomla-cms/blob/staging/administrator/components/com_content/config.xml#L472

And personally I would rename the fields and associated strings from
name="show_urls_images_backend"
to
name="show_images_backend"

This one affects user content. We need a migration plan for it. (Not saying I disagree with the idea, but this one's a little more impactful than phasing options out of the UI; even if the migration plan ends up being "create fields, copy data, have a nice day", we need something)

Good point from @mbabker - I forgot that - I guess the good part is that this wont remove any existing links from the db only a way to manage/display them

Admittedly anything beyond the "copy data to fields, have a nice day" option would quickly exceed my limited skill level so I may be biting off more than I can chew with this one. I would question how often this feature was actually used but that is based on nothing except personal opinion.

I guess generally speaking a migration plan is needed for removing such options.

@brianteeman Them particular field names I left alone as I assumed changing would have a negative b/c effect on the db?

no it shouldnt

It's bad idea...
CMS must have minimum fields,
Yes, Joomla can remove any fields like editor and image in com_content... but Joomla is a CMS that many people used it. when users update new Joomla, must do very task that maximum of their never do similar...
Please first define minimum of fields for Joomla CMS. Then Joomla.org can reduce other fields.
Imagine News Agency that used Joomla for years...
Which update can support old articles...?

This would be a HUGE issue with me. I utilize the URLs for multiple display methods.
For example. I utilize the Articles Category module for content sliders. If a content slide has a "button" or buttons. I use the Links Fields to display the button text and the URL to where it will be directed, not to mention if it should open in a new window.

I am 100000000000% against this. You are screwing a ton of developers that utilize Articles module related display.

Edit... I just did a quick count. 12 sites I maintain that utilize over 20 modules that utilize article data to display content. Content Sliders, also those fancy 3 blocks of info similar to how they are displayed on https://www.joomla.org/ except mine have two buttons at the bottom.

Those fields have been a base part of an articles content for as long as I can remember. Removal to "Simplify" a view is ridiculous.

No, no, no, no.

good , I support Remove 'Links' feature from 'Images and Links' inn j 4

I've not used this feature myself, but I know a lot of people who are using it extensively. While I like removing this and would even go as far as removing the images as well, I don't think removing this here is an option. I would aim for J5.0...

Since we already started deleting user data with xreference can we proceed with this too? ?

I'm against the PR. This is fishy, smells after trash Links, promote our plugin instead.

As GCLW pointed out in #17109 (comment), Links have been a part of Content for a long time. If 'Simplification' is a Joomla goal to reach, I'm OK to support it, but give the users a proper alternative and migration plan.

Custom fields (CFs) are one way to replace the links, but currently Links can be displayed and visualized differently from CF (and they are by default in protostar). Is it possible to manipulate the display of some selected CFs so that they mimic the look of Links? If I have to transfer all the links to CFs, I wish to have the way to make them look alike, with the same design -- but only for the transferred Links. I wish not to affect the links stored in CFs. BTW, there is no way currently that one can set link, text and target for a single CF.

I would go a totally another direction: I would like to increase the number of links dynamically, to the user needs. Sometimes I use no Links, sometimes 1-2 external links to point the user to another direction ("more info / supporting document is found elsewhere..."). But sometimes I would like to create the 4th and 5th link element, too. So, if Simplification of the edit window is a real need and issue, then give us a Links (+) code. If anybody does not use Links, they never ever see an empty field to fill in. By using a plus sign (+), a triplet of fields (link, text/name, method/target) will be populated to be filled in. More to it: No SQL change is needed: all links (1 or 3) are stored in a single cell.

@kofaysi that could be achieved with Subform field (or similar solution). But we'd have to introduce some ugly code for rebinding existing data. And we'd have to keep that code forever. As an alternative, we could add an update script to handle this, but I'm not sure how others feel about this.

Or just build on to what already exists.

URLS are A-B-C. You could add D and E rounding it to 5 Links. Yes, there would be php code and xml files to update by adding the other two "letters" but you would be updating what is already in place.
Yea, it's not dynamic, and someone could say they want 6 or 7 but there has to be a cutoff point. Or then you really do need to setup custom fields.

Also if space is an issue from an admin ux point, you could have them as a group of accordion elements. You would need to click on Link A, to open up the fields for it. Allowing only one element open at a time.

All in all, leave two database table fields alone. Every aspect of moving those out to the custom fields component is bad news. Nothing about it is "better". Not from an admin point, a resource point, or a developer point. It is an absolute blessing we have those fields to utilize where they are.

Closing... can be re-opened if required.

I believe the Links A, B and C should be removed. The custom fields can take their place.
At least add an option to hide them in the administration area. We want simpler administration forms.