@creativeopinion: thank you for the suggestion. However, this does not work. You can't use the Update Item action to set a negative integer on the field when referential integrity is enabled in SharePoint. It always fails with the following error: "The list item could not be inserted or updated because invalid lookup values were found for the following field(s) in the list: [Organization]."
In any case, there is no practical difference between your suggestion and using -1; it is just substituting one negative integer for another. After trying various way to use 'null' which was impossible, my original field formula for the Update Item action using a -1 is here, followed by your suggestion:
if(equals(variables('OrganizationID'),0),-1,variables('OrganizationID'))
if(equals(variables('OrganizationID'),0),sub(0,outputs('Get_matching_contact')?['body/Organization/Id']),variables('OrganizationID'))
The first formula results in a -1 being used; the second in a value of -58. Either one throws this error and leaves the original data in the field. This is what originally led to trying the HTTP request. The HTTP request also fails to change the value, but it fails silently (which at least has the benefit of allowing the flow to complete).
Disabling referential integrity for the column in SharePoint (see screenshot if you are unfamiliar with this) does indeed allow this to work. But then, you risk having inconsistent data in your database. For an example using my data model, an Organization could be deleted while still being referenced by Contact records, creating "orphans" in the database and introducing all kinds of problems. (Even so, SharePoint is not a real relational database and its referential integrity support is limited: you can only restrict or cascade the delete operation; there is no "set null" behavior, which is what would be desired in many cases. But we use the tools we have.)
Supposing we disable referential integrity for testing, then as you can see from the attached "Invalid Data" screenshot, using a negative integer in Power Automate does not actually clear the field; it merely sets it to an inconsistent value. We have front-end apps working against this SharePoint data in Microsoft Access. There are innumerable IsNull() checks embedded in queries, forms, reports, etc. that would all fail with data like this.
Unless I am missing something, I have to conclude that there is no current way to truly null a SharePoint Lookup column using Power Automate, and if SharePoint referential integrity is enabled, no way to even "fake it" (using a negative integer).
Microsoft should look into this.