user136: Arduino is an odd hybrid, where some C++ functionality is used in the embedded world—traditionally a C environment. Indeed, a lot of Arduino code is very C like though.
C has traditionally used #defines for constants. There are a number of reasons for this:

You can't set array sizes using const int.
You can't use const int as case statement labels (though this does work in some compilers)
You can't initialize a const with another const.

You can check this question on StackOverflow for more reasoning.
So, what should we use for Arduino? I tend towards #define, but I see some code using const and some using a blend.

user26717: For variables of a specified type which are not altered during execution, either can usually be used.
For Digital pin numbers contained in variables, either can work - such as:
const int ledPin = 13;

But there is one circumstance where I always use #define
It is to define analog pin numbers, since they are alphanumeric.
Sure, you can hard-code the pin numbers as a2, a3, etc. all throughout the program and the compiler will know what to do with them.  Then if you change pins then each use would need to be changed.
Moreover, I always like to have my pin definitions up at the top all in one place, so the question becomes which type of const would be appropriate for a pin defined as A5.
In those cases I always use #define
Voltage Divider Example:
//
//  read12     Reads Voltage of 12V Battery
//
//        SDsolar      8/8/18
//
#define adcInput A5    // Voltage divider output comes in on Analog A5
float R1 = 120000.0;   // R1 for voltage divider input from external 0-15V
float R2 =  20000.0;   // R2 for voltage divider output to ADC
float vRef = 4.8;      // 9V on Vcc goes through the regulator
float vTmp, vIn;
int value;
.
.
void setup() {
.
// allow ADC to stabilize
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin);
.
void loop () {
.
.
  value=analogRead(adcPin);
  vTmp = value * ( vRef / 1024.0 );  
  vIn = vTmp / (R2/(R1+R2)); 
 .
 .

All the setup variables are right at the top and there is never going to be a change to the value of adcPin except at compile time.
No worries about what type adcPin is.  And no extra RAM is used in the binary to store a constant.  
The compiler simply replaces each instance of adcPin with the string A5 before compiling.

There is an interesting Arduino Forum thread that discusses other ways to decide:
#define vs. const variable  (Arduino forum)
Excertps:
Code substitution:
#define FOREVER for( ; ; )

FOREVER
 {
 if (serial.available() > 0)
   ...
 }

Debugging code:
#ifdef DEBUG
 #define DEBUG_PRINT(x) Serial.println(x)
#else
 #define DEBUG_PRINT(x)
#endif

Defining true and false as Boolean to save RAM
Instead of using `const bool true = 1;` and same for `false`

#define true (boolean)1
#define false (boolean)0


A lot of it comes down to personal preference, however it is clear that #define is more versatile.

user42: EDIT: microtherion gives an excellent answer which corrects some of my points here, particularly about memory usage.

As you've identified, there are certain situations where you're forced to use a #define, because the compiler won't allow a const variable. Similarly, in some situations you're forced to use variables, such as when you need an array of values (i.e. you can't have an array of #define).
However, there are many other situations where there isn't necessarily a single 'correct' answer. Here are some guidelines which I would follow:
Type safety
From a general programming point-of-view, const variables are usually preferable (where possible). The main reason for that is type-safety.
A #define (preprocessor macro) directly copies the literal value into each location in code, making every usage independent. This can hypothetically result in ambiguities, because the type may end up being resolved differently depending on how/where it's used.
A const variable is only ever one type, which is determined by its declaration, and resolved during initialisation. It will often require an explicit cast before it will behave differently (although there are various situations where it can safely be implicitly type-promoted). At the very least, the compiler can (if configured correctly) emit a more reliable warning when a type issue occurs.
A possible workaround for this is to include an explicit cast or a type-suffix within a #define. For example:
#define THE_ANSWER (int8_t)42
#define NOT_QUITE_PI 3.14f

That approach can potentially cause syntax problems in some cases though, depending on how it's used.
Memory usage
Unlike general purpose computing, memory is obviously at a premium when dealing with something like an Arduino. Using a const variable vs. a #define can affect where the data is stored in memory, which may force you to use one or the other.

const variables will (usually) be stored in SRAM, along with all other variables.
Literal values used in #define will often be stored in program space (Flash memory), alongside the sketch itself.

(Note that there are various things which can affect exactly how and where something is stored, such as compiler configuration and optimisation.)
SRAM and Flash have different limitations (e.g. 2 KB and 32 KB respectively for the Uno). For some applications, it's quite easy to run out of SRAM, so it can be helpful to shift some things into Flash. The reverse is also possible, although probably less common.
PROGMEM
It's possible to get the benefits of type-safety while also storing the data in program space (Flash). This is done using the PROGMEM keyword. It doesn't work for all types, but it's commonly used for arrays of integers or strings.
The general form given in the documentation is as follows:
dataType variableName[] PROGMEM = {dataInt0, dataInt1, dataInt3...}; 

String tables are a bit more complicated, but the documentation has full details.

user353: It's important to note that const int does not behave identically in C and in C++, so in fact several of the objections against it that have been alluded to in the original question and in Peter Bloomfields's extensive answer are not valid:

In C++, const int constants are compile time values and can be used to set array limits, as case labels, etc.
const int constants do not necessarily occupy any storage. Unless you take their address or declare them extern, they will generally just have a compile time existence.

However, for integer constants, it might often be preferable to use a (named or anonymous) enum. I often like this because:

It's backward compatible with C.
It's nearly as type safe as const int (every bit as type safe in C++11).
It provides a natural way of grouping related constants.
You can even use them for some amount of namespace control.

So in an idiomatic C++ program, there is no reason whatsoever to use #define to define an integer constant. Even if you want to remain C compatible (because of technical requirements, because you're kickin' it old school, or because people you work with prefer it that way), you can still use enum and should do so, rather than use #define. 

136: <p>Arduino is an odd hybrid, where some C++ functionality is used in the embedded world—traditionally a C environment. Indeed, a lot of Arduino code is very C like though.</p>

<p>C has traditionally used <code>#define</code>s for constants. There are a number of reasons for this:</p>

<ol>
<li>You can't set array sizes using <code>const int</code>.</li>
<li>You can't use <code>const int</code> as case statement labels (though this does work in some compilers)</li>
<li>You can't initialize a <code>const</code> with another <code>const</code>.</li>
</ol>

<p>You can check <a href="https://stackoverflow.com/questions/1674032/static-const-vs-define-in-c">this question</a> on StackOverflow for more reasoning.</p>

<p>So, what should we use for Arduino? I tend towards <code>#define</code>, but I see some code using <code>const</code> and some using a blend.</p>
 26717: <p><strong>For variables of a specified type which are not altered during execution, either can usually be used.</strong></p>

<p><strong>For Digital pin numbers contained in variables, either can work - such as:</strong></p>

<pre><code>const int ledPin = 13;
</code></pre>

<p><strong>But there is one circumstance where I always use <code>#define</code></strong></p>

<p><strong>It is to define analog pin numbers, since they are alphanumeric.</strong></p>

<p>Sure, you can hard-code the pin numbers as <code>a2</code>, <code>a3</code>, etc. all throughout the program and the compiler will know what to do with them.  Then if you change pins then each use would need to be changed.</p>

<p>Moreover, I always like to have my pin definitions up at the top all in one place, so the question becomes which type of <code>const</code> would be appropriate for a pin defined as <code>A5</code>.</p>

<p>In those cases I always use <code>#define</code></p>

<p><strong>Voltage Divider Example:</strong></p>

<pre><code>//
//  read12     Reads Voltage of 12V Battery
//
//        SDsolar      8/8/18
//
#define adcInput A5    // Voltage divider output comes in on Analog A5
float R1 = 120000.0;   // R1 for voltage divider input from external 0-15V
float R2 =  20000.0;   // R2 for voltage divider output to ADC
float vRef = 4.8;      // 9V on Vcc goes through the regulator
float vTmp, vIn;
int value;
.
.
void setup() {
.
// allow ADC to stabilize
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin); delay(50);
value=analogRead(adcPin); delay(50); value=analogRead(adcPin);
.
void loop () {
.
.
  value=analogRead(adcPin);
  vTmp = value * ( vRef / 1024.0 );  
  vIn = vTmp / (R2/(R1+R2)); 
 .
 .
</code></pre>

<p>All the setup variables are right at the top and there is never going to be a change to the value of <code>adcPin</code> except at compile time.</p>

<p>No worries about what type <code>adcPin</code> is.  And no extra RAM is used in the binary to store a constant.  </p>

<p>The compiler simply replaces each instance of <code>adcPin</code> with the string <code>A5</code> before compiling.</p>

<hr>

<p>There is an interesting Arduino Forum thread that discusses other ways to decide:</p>

<p><a href="https://forum.arduino.cc/index.php?topic=44023.0" rel="nofollow noreferrer">#define vs. const variable</a>  (Arduino forum)</p>

<p>Excertps:</p>

<p>Code substitution:</p>

<pre><code>#define FOREVER for( ; ; )

FOREVER
 {
 if (serial.available() &gt; 0)
   ...
 }
</code></pre>

<p>Debugging code:</p>

<pre><code>#ifdef DEBUG
 #define DEBUG_PRINT(x) Serial.println(x)
#else
 #define DEBUG_PRINT(x)
#endif
</code></pre>

<p>Defining <code>true</code> and <code>false</code> as Boolean to save RAM</p>

<pre><code>Instead of using `const bool true = 1;` and same for `false`

#define true (boolean)1
#define false (boolean)0
</code></pre>

<hr>

<p>A lot of it comes down to personal preference, however it is clear that <code>#define</code> is more versatile.</p>
 42: <p><em>EDIT: microtherion gives an excellent answer which corrects some of my points here, particularly about memory usage.</em></p>

<hr>

<p>As you've identified, there are certain situations where you're forced to use a <code>#define</code>, because the compiler won't allow a <code>const</code> variable. Similarly, in some situations you're forced to use variables, such as when you need an array of values (i.e. you can't have an array of <code>#define</code>).</p>

<p>However, there are many other situations where there isn't necessarily a single 'correct' answer. Here are some guidelines which I would follow:</p>

<p><strong>Type safety</strong><br>
From a general programming point-of-view, <code>const</code> variables are usually preferable (where possible). The main reason for that is type-safety.</p>

<p>A <code>#define</code> (preprocessor macro) directly copies the literal value into each location in code, making every usage independent. This can hypothetically result in ambiguities, because the type may end up being resolved differently depending on how/where it's used.</p>

<p>A <code>const</code> variable is only ever one type, which is determined by its declaration, and resolved during initialisation. It will often require an explicit cast before it will behave differently (although there are various situations where it can safely be implicitly type-promoted). At the very least, the compiler can (if configured correctly) emit a more reliable warning when a type issue occurs.</p>

<p>A possible workaround for this is to include an explicit cast or a type-suffix within a <code>#define</code>. For example:</p>

<pre><code>#define THE_ANSWER (int8_t)42
#define NOT_QUITE_PI 3.14f
</code></pre>

<p>That approach can potentially cause syntax problems in some cases though, depending on how it's used.</p>

<p><strong>Memory usage</strong><br>
Unlike general purpose computing, memory is obviously at a premium when dealing with something like an Arduino. Using a <code>const</code> variable vs. a <code>#define</code> can affect where the data is stored in memory, which may force you to use one or the other.</p>

<ul>
<li><code>const</code> variables will (usually) be stored in SRAM, along with all other variables.</li>
<li>Literal values used in <code>#define</code> will often be stored in program space (Flash memory), alongside the sketch itself.</li>
</ul>

<p><em>(Note that there are various things which can affect exactly how and where something is stored, such as compiler configuration and optimisation.)</em></p>

<p>SRAM and Flash have different limitations (e.g. 2 KB and 32 KB respectively for the Uno). For some applications, it's quite easy to run out of SRAM, so it can be helpful to shift some things into Flash. The reverse is also possible, although probably less common.</p>

<p><strong>PROGMEM</strong><br>
It's possible to get the benefits of type-safety while also storing the data in program space (Flash). This is done using the <code>PROGMEM</code> keyword. It doesn't work for all types, but it's commonly used for arrays of integers or strings.</p>

<p>The general form given in the <a href="http://arduino.cc/en/Reference/PROGMEM" rel="noreferrer"><strong>documentation</strong></a> is as follows:</p>

<pre><code>dataType variableName[] PROGMEM = {dataInt0, dataInt1, dataInt3...}; 
</code></pre>

<p>String tables are a bit more complicated, but the documentation has full details.</p>
 353: <p>It's important to note that <code>const int</code> does <strong>not</strong> behave identically in C and in C++, so in fact several of the objections against it that have been alluded to in the original question and in Peter Bloomfields's extensive answer are not valid:</p>

<ul>
<li>In C++, <code>const int</code> constants are compile time values and <strong>can</strong> be used to set array limits, as case labels, etc.</li>
<li><code>const int</code> constants do not necessarily occupy any storage. Unless you take their address or declare them extern, they will generally just have a compile time existence.</li>
</ul>

<p>However, for integer constants, it might often be preferable to use a (named or anonymous) <code>enum</code>. I often like this because:</p>

<ul>
<li>It's backward compatible with C.</li>
<li>It's nearly as type safe as <code>const int</code> (every bit as type safe in C++11).</li>
<li>It provides a natural way of grouping related constants.</li>
<li>You can even use them for some amount of namespace control.</li>
</ul>

<p>So in an idiomatic C++ program, there is no reason whatsoever to use <code>#define</code> to define an integer constant. Even if you want to remain C compatible (because of technical requirements, because you're kickin' it old school, or because people you work with prefer it that way), you can still use <code>enum</code> and should do so, rather than use <code>#define</code>. </p>
