it's the same

Low level yes but...

• does not make it very readable.
• implicit type conversion(s)

OK, I'll change this tomorrow.
Do you know why this wired return value?

Why the weird return value?
According to this help the function is supposed to return a value of type int for SM_CYFRAME (or maybe better SM_CYSIZEFRAME) representing the thickness of the sizing border around the perimeter of a window that can be resized, in pixels.
So my question is: is it a resizable frame i.e. is the correct metric retrieved?

In addition to 'true' vs '1':
When the return value represents Boolean data a nonzero value is considered true and a zero value is considered false. Most of the Windows functions that return Boolean data return a value of type BOOL (TRUE or FALSE) which is different from the C++ native type bool (true or false).

int reply = ::GetSystemMetrics( SM_DBCSENABLED);
if (reply != 0) // using 'if (reply)' would add an implicit type conversion (int --> bool)
    // User32.dll w/ DBCS support
else
    // User32.dll w/o DBCS support

Could be written as...

BOOL reply = ::GetSystemMetrics( SM_DBCSENABLED);
if (reply == TRUE) // using 'if (reply)' would add an implicit type conversion (int --> bool)
    // User32.dll w/ DBCS support
else
    // User32.dll w/o DBCS support

or as...

bool isEnabled = (TRUE == ::GetSystemMetrics( SM_DBCSENABLED));
if (isEnabled)
    // User32.dll w/ DBCS support
else
    // User32.dll w/o DBCS support

is it a resizable frame i.e. is the correct metric retrieved?

This is the correct metric for the WS_THICKFRAME Style. The return value is correct for other windows with this style. For the Task List dialog I get this values:

100% - return: 8  - is: 7
150% - return: 11 - is: 10
200% - return: 13 - is: 12

The Task List border is 1px smaller, so I assume it is safe to simply decrement the return value.

In addition to 'true' vs '1': ...

I don't see the point here. I'm aware of this all. There is no 'bad' with the code above. It is absolutely safe to replace 1 with true.

The return value is correct for other windows ...

I have no idea, yet. Makes it a bigger challenge finding out though ;)
Maybe the returned values are correct. Does the TaskList look wrong without the correction? Probably yes, otherwise you wouldn't have applied the correction.
I would check for it myself but I'm currently not able to compile the application and see the differences.

... I assume it is safe to simply decrement the return value.

Assumptions are always BAD, at some point in time they will bite you in the a...
These should always be well documented (as you did)!

In addition to 'true' vs '1': ...

I was not sure you were aware, just discard it.
Although, IMO it's 'bad' when it raises confusion/questions, degrades readability despite raising neither errors nor warnings by compiler :)

Heap vs. stack, leads to a better performance. But in this case there is probably no difference.