Core

Are you testing on latest master branch?
Is your DB up to date?

Yes, I'm on latest master branch and PostgreSQL is up to date.

Ah ok, then I was mislead. You didn't mention that DBAL is active ;-)

So you need to search backwards where this second argument stems from. I guess from some DB query that fails.
Did you enable the Development-Preset in the Install Tool? A failed SQL query should show up then in the BE.
(If it happens in an AJAX request, check the content returned by that request, it will contain the backtrace.)

Develoment preset is active and I find no SQL related error. But you're right, a syntaxe error is returned in a JSON answer from typo3/ajax.php?ajaxID=ExtDirect::route&namespace=TYPO3.Components.PageTree:

[{"tid":6,"action":"Commands","method":"insertNodeAfterDestination","type":"rpc","result":{"success":false,"message":"PHP Catchable Fatal Error: Argument 2 passed to TYPO3\\CMS\\Backend\\Utility\\IconUtility::getSpriteIconForRecord() must be of the type array, null given, called in C:\\wamp\\www\\TYPO3.CMS\\typo3\\sysext\\backend\\Classes\\Tree\\Pagetree\\Commands.php on line 350 and defined in C:\\wamp\\www\\TYPO3.CMS\\typo3\\sysext\\backend\\Classes\\Utility\\IconUtility.php line 693"},"debug":""}]

And this problem remains in master dev branch.

The error itself it caused by $record being NULL, but $record['uid'] !== 0 returns TRUE. We can patch this for now, but the cause has to be tackled down to it's source.

Can you please head to the method getNodeRecord in typo3/sysext/backend/Classes/Tree/Pagetree/Commands.php and debug the content of $record?

$record is empty in getNodeRecord. But tracking further to getRecordWSOL in BackendUtility.php I loose any error information (though the error message is still here).

The problem is an unsafe comparison

if ($record['uid'] !== 0) {

I'm sure that $record comes from DB directly and therefore 'uid' is of type string and not int, so the comparison is wrong.

Can you try changing this to:

if ((int)$record['uid'] !== 0) {

This line dates back to #24250

When I cast $record['uid'] to int and I try to add a new page, I get an exception [1.4.14]: Attempt to move record '[root-level]' (pages:) without having permissions to do so.

So you have the proof that your $record is not there. The cast to int now gives 0 for the uid, which is the "[root-level]".
You have to trace back, where $record gets its data from. There is something wrong.

The int-cast thing will be solved with: #67138

I deleted every page records, attempted tp add a new standard page below root: it creates a new root page with no id, [No Title] and a new page below... Strange, isn't it?
I'm trying to trace $record back.
EDIT: $record gets its data from BackendUtility::getRecordWSOL

Basically there is a thing I hardly understand: in my database, I have only 1 page record (with id=60), when I echo $record['uid'] i get both root id (0) and my page id (60): so if ((int)$record['uid'] !== 0) comparison results both TRUE and FALSE, is it a normal behaviour?

when I echo $record['uid'] i get both root id (0) and my page id (60)

you mean $record['uid'] holds 2 values??

Exactly, on echo $record['uid'] I get 060

That is for sure a major problem. I debugged it here locally and this is always a normal record for me.

Do you have workspaces installed? If so, please disable it and try if it works without it.

?? Do you have workspaces installed? ??
I don't actually know... How can I check this?

Extension Manager. Extension is called "workspaces"

Worspaces is already inactive.

Then the DB driver delivers very strange results. You've to check BackendUtility::getRecord then.

Everything looks fine in BackendUtility::getRecord(). But a strange things occures: $record is created in Commands.php:getNodeRecord() from an instance of BackendUtility::getRecordWSOL(); result viewed in getRecordWSOL() is an array containing data taken from my only page record (each field is a string), but in getNodeRecord() it is null and the user right exception is raised!

Exception message "[1.4.14]: Attempt to move record '[root-level]' (pages:) without having permissions to do so." is originated in ExtdirectTreeCommands:insertNodeAfterDestination(). There, the try bloc seems not to be executed.

I think this is due to a bug exec_INSERTquery() in the DBAL DataseConnection.php

If you look at line 524 you'll see that the last_insert_id isn't updated after the statement, as a result a subsequent call to sql_insert_id() will return a possibly wrong value (of a previous statement or the default value 0). Returning the default value seems to be what is happening here.

Thanks for pointing things out Markus and Morton, I think i solved the problem (at least it works on my local).
EDIT: since I can't commit a patch for review (for now), here is the raw change I made in [[https://github.com/TYPO3/TYPO3.CMS/blob/master/typo3/sysext/dbal/Classes/Database/DatabaseConnection.php#L524]]:

524           $sqlResult = $this->handlerInstance[$this->lastHandlerKey]->_query($this->lastQuery, FALSE);
525  (ADDED)  $new_id = $this->handlerInstance[$this->lastHandlerKey]->Insert_ID($table, $this->cache_autoIncFields[$table]);
526  (ADDED)  $this->handlerInstance[$this->lastHandlerKey]->last_insert_id = $new_id;